Ynlieding

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

Lykas by it konsept fan in absolút sterke sifer út kryptografy, besykje echte "Publicly Verifiable Random Beacon" (hjirnei PVRB) protokollen allinich sa ticht mooglik by it ideale skema te kommen, om't yn echte netwurken is it net fan tapassing yn syn suvere foarm: it is needsaaklik om strikt oer ien bit iens te wurden, d'r moatte in protte rûnten wêze, en alle berjochten moatte perfekt fluch en altyd levere wurde. Fansels is dit net it gefal yn echte netwurken. Dêrom, by it ûntwerpen fan PVRB's foar spesifike taken yn moderne blockchains, neist de ûnmooglikheid om de resultearjende willekeur en kryptografyske krêft te kontrolearjen, ûntsteane folle mear suver arsjitektoanyske en technyske problemen.

Foar PVRB is de blockchain sels yn wêzen in kommunikaasjemedium wêryn berjochten = transaksjes. Hjirmei kinne jo foar in part abstrahere fan netwurkproblemen, net-levering fan berjochten, problemen mei middleware - al dizze risiko's wurde oannommen troch it desintralisearre netwurk, en har haadwearde foar PVRB is it ûnfermogen om in al ferstjoerde transaksje yn te lûken of te korrupsje - dit docht dielnimmers net tastean om te wegerjen om diel te nimmen oan it protokol, útsein as se in suksesfolle oanfal op konsensus útfierden. Dit nivo fan feiligens is akseptabel, dus PVRB moat resistint wêze foar gearspanning troch dielnimmers yn krekt deselde mjitte as de haadblokketting. Ek, dit hints dat de PVRB moat wêze in part fan de konsensus as it netwurk iens op 'e wichtichste blockchain, sels as it ek iens op' e ienige earlike resultearjende willekeurich. Of, PVRB is gewoan in standalone protokol ymplementearre troch in tûk kontrakt dat asynchronous wurket mei respekt foar de blockchain en blokken. Beide metoaden hawwe har foardielen en neidielen, en de kar tusken har is ekstreem net-trivial.

Twa manieren om PVRB út te fieren

Lit ús twa opsjes foar it útfieren fan PVRB yn mear detail beskriuwe - de standalone ferzje, dy't wurket mei in tûk kontrakt ûnôfhinklik fan 'e blockchain, en de konsensus-yntegreare ferzje, ynboud yn it protokol, neffens dêr't it netwurk it iens is oer de blockchain en de transaksjes wurde opnommen. Yn alle gefallen sil ik populêre blockchain-motoren betsjutte: Ethereum, EOS, en al dy ferlykber mei har yn 'e manier wêrop se tûke kontrakten hostje en ferwurkje.

Standalone kontrakt

Yn dizze ferzje, PVRB is in tûk kontrakt dat akseptearret transaksjes fan willekeurige produsinten (hjirnei oantsjutten as RP), ferwurket se, kombinearret de resultaten, en, as gefolch, komt op in bepaalde wearde dat eltse brûker kin ûntfange út dit kontrakt. Dizze wearde kin net direkt yn 'e kontrakt opslein wurde, mar allinich fertsjintwurdige wurde troch gegevens wêrfan ien en mar ien wearde fan' e resultearjende willekeurich deterministysk kin wurde krigen. Yn dit skema binne RP's brûkers fan 'e blockchain, en elkenien kin meidwaan oan it generaasjeproses.

De opsje mei standalone-kontrakt is goed:

• portabiliteit (kontrakten kinne wurde sleept fan blockchain nei blockchain)
• gemak fan ymplemintaasje en testen (kontrakten binne maklik te skriuwen en te testen)
• gemak by it útfieren fan ekonomyske regelingen (it is maklik om jo eigen token te meitsjen, waans logika de doelen fan PVRB tsjinnet)
• mooglikheid fan lansearring op al wurkjende blockchains

It hat ek neidielen:

• sterke beheiningen op komputerboarnen, transaksjevolumint en opslach (mei oare wurden, cpu / mem / io)
• beheiningen op operaasjes binnen it kontrakt (net alle ynstruksjes binne beskikber, it is lestich om eksterne biblioteken te ferbinen)
• ûnfermogen om berjochten rapper te organisearjen dan transaksjes binne opnommen yn 'e blockchain

Dizze opsje is geskikt foar it útfieren fan in PVRB dy't moat wurde útfierd op in besteande netwurk, befettet gjin komplekse kryptografy en fereasket gjin grut oantal ynteraksjes.

Konsensus-yntegreare

Yn dizze ferzje wurdt PVRB ymplementearre yn 'e blockchain-knooppuntkoade, ynboud as parallel mei de útwikseling fan berjochten tusken blockchain-knooppunten. De resultaten fan it protokol wurde direkt yn 'e produsearre blokken skreaun, en protokolberjochten wurde ferstjoerd oer it p2p-netwurk tusken knopen. Sûnt it protokol resultearret yn nûmers dy't yn blokken skreaun wurde moatte, moat it netwurk in konsensus oer har berikke. Dit betsjut dat PVRB-berjochten, lykas transaksjes, moatte wurde falidearre troch knooppunten en opnommen yn blokken, sadat elke netwurk-dielnimmer de konformiteit mei it PVRB-protokol validearje kin. Dit liedt ús automatysk nei de foar de hân lizzende oplossing - as it netwurk it iens is oer in konsensus oer in blok en transaksjes dêryn, dan moat PVRB diel útmeitsje fan 'e konsensus, en net in stand-alone protokol. Oars is it mooglik dat in blok jildich is út in konsensus eachpunt, mar it PVRB protokol wurdt net folge, en út it PVRB eachpunt kin it blok net akseptearre wurde. Dus as de opsje "konsensus-yntegreare" wurdt keazen, wurdt de PVRB in wichtich ûnderdiel fan 'e konsensus.

By it beskriuwen fan PVRB-ymplemintaasjes op it netwurkkonsensusnivo kin men op gjin inkelde manier problemen fan finaliteit foarkomme. Finaliteit is in meganisme dat brûkt wurdt yn deterministyske konsensussen dy't in blok (en de keatling dy't dêrta liedt) slút, dat is definityf en sil nea wurde smiten fuort, sels as in parallelle foarke optreedt. Bygelyks, yn Bitcoin is d'r gjin sa'n meganisme - as jo in keten fan gruttere kompleksiteit publisearje, sil it elke minder komplekse ferfange, nettsjinsteande de lingte fan 'e keatlingen. En yn EOS, bygelyks, de lêste binne de saneamde Last Irreversible Blocks, dy't ferskine yn trochsneed alle 432 blokken (12 * 21 + 12 * 15, pre-vote + pre-commit). Dit proses wachtet yn wêzen op 2/3 fan blokprodusinten (hjirnei oantsjutten as BP) hantekeningen. Wannear't foarken ferskine dy't âlder binne as de lêste LIB, wurde se gewoanwei wegere. Dit meganisme makket it mooglik om te garandearjen dat de transaksje is opnaam yn 'e blockchain en sil nea wurde rôle werom, nettsjinsteande hokker middels de oanfaller hat. Ek binne de lêste blokken blokken tekene troch 2/3 BP yn Hyperledger, Tendermint en oare pBFT-basearre konsensussen. Ek makket it sin om in protokol te meitsjen foar it garandearjen fan finaliteit in tafoeging oan konsensus, om't it asynchronysk kin wurkje mei de produksje en publikaasje fan blokken. Hjir is in goeie artikel oer finaliteit yn Ethereum.

Finality is ekstreem wichtich foar brûkers, dy't sûnder it meie fine harsels slachtoffers fan in "dûbele spend" oanfal, dêr't BP "hold" blokken, en publisearret se neidat it netwurk hat "sjoen" in goede transaksje. As der gjin finaliteit is, dan ferfangt de publisearre gabel it blok mei in "goede" transaksje mei in oar, fan in "minne" gabel, wêryn deselde fûnsen wurde oerdroegen oan it adres fan 'e oanfaller. Yn it gefal fan PVRB binne de easken foar finaliteit noch stranger, om't it bouwen fan foarken foar PVRB de kâns betsjut foar in oanfaller om ferskate willekeurige opsjes te meitsjen om de meast rendabele te publisearjen, en it beheinen fan 'e tiid fan in mooglike oanfal is in goede oplossing.

Dêrom is de bêste opsje om PVRB en finaliteit te kombinearjen yn ien protokol - dan is it finalisearre blok = finalisearre willekeurich, en dit is krekt wat wy nedich hawwe om te krijen. No spilers sille ûntfange in garandearre willekeurich yn N sekonden, en kin der wis fan wêze dat it is ûnmooglik om te rôlje it werom of replay it wer.

De konsensus-yntegreare opsje is goed:

• de mooglikheid fan asynchrone ymplemintaasje yn relaasje ta de produksje fan blokken - blokken wurde produsearre as gewoanlik, mar parallel mei dit kin it PVRB-protokol wurkje, wat gjin willekeur foar elke blok produsearret
• de mooglikheid om sels swiere kryptografy út te fieren, sûnder de beheiningen oplein op tûke kontrakten
• de mooglikheid om de útwikseling fan berjochten flugger te organisearjen as transaksjes binne opnommen yn 'e blockchain, bygelyks in diel fan it protokol kin wurkje tusken knopen sûnder berjochten oer it netwurk te fersprieden

It hat ek neidielen:

• Swierrichheden by testen en ûntwikkeljen - jo sille netwurkflaters moatte emulearje, ûntbrekkende knopen, hurde foarken fan netwurk
• Implementaasje flaters fereaskje in netwurk hardfork

Beide metoaden foar it útfieren fan PVRB hawwe in rjocht op it libben, mar ymplemintaasje op tûke kontrakten yn moderne blockchains is noch frij beheind yn komputerboarnen, en elke oergong nei serieuze kryptografy is faak gewoan ûnmooglik. En wy sille serieuze kryptografy nedich wêze, lykas hjirûnder oantoand. Hoewol dit probleem dúdlik tydlik is, is serieuze kryptografy yn kontrakten nedich om in protte problemen op te lossen, en it ferskynt stadichoan (bygelyks systeemkontrakten foar zkSNARKs yn Ethereum)

Blockchain, dy't in transparant en betrouber protokol-berjochtenkanaal leveret, docht dat net fergees. Elk desintralisearre protokol moat rekken hâlde mei de mooglikheid fan in Sybil-oanfal; elke aksje kin dien wurde troch de gearwurkjende krêften fan meardere akkounts, dus, by it ûntwerpen, is it nedich om rekken te hâlden mei it fermogen fan oanfallers om in willekeurich oantal protokol te meitsjen dielnimmers hannelje yn gearspanning.

PVRB en blok fariabelen.

Ik lei net doe't ik sei dat gjinien noch hat útfierd in goede PVRB, hifke troch in protte gokken applikaasjes, yn blockchains. Wêr komt dan safolle gokken applikaasjes út op Ethereum en EOS? Dit fernuveret my safolle as it fernuveret jo, wêr kamen se safolle "oanhâldende" willekeurich yn in folslein deterministyske omjouwing?

De favorite manier om willekeur te krijen yn 'e blockchain is in soarte fan "ûnfoarspelbere" ynformaasje fan it blok te nimmen en in willekeurige te meitsjen op basis dêrfan - gewoan troch ien of mear wearden te hashen. Goed artikel oer de problemen fan sokke regelingen hjir. Jo kinne ien fan 'e "ûnfoarspelbere" wearden yn it blok nimme, bygelyks de blokhash, it oantal transaksjes, netwurkkompleksiteit, en oare wearden dy't fan tefoaren bekend binne. Hash se dan, ien of mear, en, yn teory, moatte jo in echte willekeur krije. Jo kinne sels tafoegje oan it wihitepaper dat jo skema "post-quantum feilich" is (omdat d'r kwantumbestindige hashfunksjes binne :)).

Mar sels post-quantum feilige hashes binne net genôch, helaas. It geheim leit yn 'e easken foar PVRB, lit my jo derfan herinnerje út it foarige artikel:

1. It resultaat moat in blykber unifoarme ferdieling hawwe, dus basearre op bewiisber sterke kryptografy.
2. It is net mooglik om ien fan 'e bits fan it resultaat te kontrolearjen. As gefolch, de útkomst kin net foarsizze wurde.
3. Jo kinne it generaasjeprotokol net sabotearje troch net mei te dwaan oan it protokol of troch it netwurk te oerladen mei oanfalsberjochten
4. Al it boppesteande moat resistint wêze foar gearspanning fan in tastien oantal ûnearlike protokol-dielnimmers (bygelyks 1/3 fan 'e dielnimmers).

Yn dit gefal wurdt allinich eask 1 foldien, en eask 2 is net foldien. Troch ûnfoarspelbere wearden út it blok te hashen, krije wy in unifoarme ferdieling en goede willekeurich. Mar BP hat op syn minst de opsje om "it blok te publisearjen of net." Sa kin BP op syn minst kieze út TWEE willekeurige opsjes: "sin eigen" en dyjinge dy't sil blike as immen oars makket it blok. BP kin fan tefoaren "snoopje" wat der barre sil as hy in blok publisearret, en gewoan beslút om it te dwaan of net. Sa, doe't spyljen, Bygelyks, "even-ûneven" of "read / swart" yn roulette, hy kin publisearje in blok allinnich as hy sjocht in winst. Dit makket ek de strategy fan it brûken fan bygelyks in blokhash "út 'e takomst" ûnwurkber. Yn dit gefal sizze se dat "willekeurich wurdt brûkt, dat wurdt krigen troch it hashjen fan de hjoeddeistige gegevens en de hash fan in takomstich blok mei in hichte fan bygelyks N + 42, wêrby't N de hjoeddeistige blokhichte is. Dit fersterket it skema in bytsje, mar lit BP dochs, hoewol yn 'e takomst, kieze om it blok te hâlden of te publisearjen.

BP software yn dit gefal wurdt yngewikkelder, mar net folle. Gewoanwei, by it falidearjen en opnimmen fan in transaksje yn in blok, is d'r in flugge kontrôle om te sjen oft d'r in winst sil wêze, en, mooglik, seleksje fan ien transaksjeparameters om in hege kâns op winst te krijen. Tagelyk is it hast ûnmooglik om in tûke BP te fangen foar sokke manipulaasjes; elke kear kinne jo nije adressen brûke en bytsje by bytsje winne sûnder fertinking te wekken.

Sa metoaden mei help fan ynformaasje út it blok binne net geskikt as in universele ymplemintaasje fan PVRB. Yn in beheinde ferzje, mei beheiningen op innsatsstorrelsen, beheinings op it oantal spilers en / of KYC registraasje (om foar te kommen dat ien spiler in gebrûk meardere adressen), dizze regelingen kinne wurkje foar lytse spultsjes, mar neat mear.

PVRB en commit-reveal.

Okee, tank oan hashing en op syn minst de relative ûnfoarspelberens fan 'e blokhash en oare fariabelen. As jo ​​it probleem fan front-running miners oplosse, moatte jo wat mear gaadliker krije. Litte wy brûkers tafoegje oan dit skema - lit se ek de willekeur beynfloedzje: elke technyske stipemeiwurker sil jo fertelle dat it meast willekeurige ding yn IT-systemen de aksjes fan brûkers binne :)

In naïve skema, as brûkers gewoan willekeurige nûmers stjoere en it resultaat wurdt berekkene as bygelyks in hash fan har som, is net geskikt. Yn dit gefal kin de lêste spiler, troch syn eigen willekeurich te kiezen, kontrolearje wat it resultaat sil wêze. Dit is de reden dat it heul wiid brûkte commit-reveal-patroan wurdt brûkt. Dielnimmers stjoere earst hashes fan har randoms (commits), en iepenje dan de randoms sels (reveals). De "reveal" faze begjint pas neidat de nedige commits binne sammele, sadat dielnimmers kinne stjoere krekt de willekeurige hash út dêr't se stjoerde earder. No litte wy dit alles byinoar sette mei de parameters fan in blok, en better as ien fan 'e takomst (willekeurigens kin allinich fûn wurde yn ien fan' e takomstige blokken), en voila - de willekeur is klear! No beynfloedet elke spiler de resultearjende willekeur, en kin de kweade BP "ferslaan" troch it te oerskriuwen mei syn eigen, foarôf ûnbekende, willekeurichheid ... Jo kinne ek beskerming tafoegje tsjin sabotearjen fan it protokol troch it net te iepenjen yn it iepenbieringsstadium - gewoanwei troch te easkjen dat in bepaald bedrach oan 'e transaksje wurdt hechte by it begean - in boarchsom, dy't allinich sil wurde weromjûn tidens de iepenbieringsproseduere. Yn dit gefal sil ynsette en net iepenbierje net rendabel wêze.

It wie in goede poging, en sokke regelingen bestean ek yn gaming DApps, mar och, dit is wer net genôch. No kin net allinich de miner, mar ek elke dielnimmer oan it protokol it resultaat beynfloedzje. It is noch altyd mooglik om de wearde sels te kontrolearjen, mei minder fariabiliteit en op kosten, mar, lykas yn 't gefal fan' e miner, as de resultaten fan 'e tekening weardefoller binne as de fergoeding foar dielname oan it PVRB-protokol, dan is de willekeurich -produsint (RP) kin beslute oft te iepenbierjen en kin noch kieze út op syn minst twa willekeurige opsjes.
Mar it waard mooglik om te straffen dyjingen dy't commit en net iepenbierje, en dit skema sil komme fan pas. De ienfâld is in serieus foardiel - serieuze protokollen fereaskje folle machtiger berekkeningen.

PVRB en deterministyske hantekeningen.

D'r is in oare manier om de RP te twingen om in pseudo-willekeurich nûmer te leverjen dat it net kin beynfloedzje as it is foarsjoen fan in "foarbyld" - dit is in deterministyske hantekening. Sa'n hântekening is bygelyks RSA, en is net ECS. As RP in pear kaaien hat: RSA en ECC, en hy tekenet in bepaalde wearde mei syn priveekaai, dan sil hy yn it gefal fan RSA IEN EN ONLY ONE hântekening krije, en yn it gefal fan ECS kin hy elk oantal generearje ferskillende jildige hantekeningen. Dit komt omdat by it meitsjen fan in ECS-hântekening, in willekeurich getal wurdt brûkt, keazen troch de ûndertekener, en it kin wurde keazen op hokker wize, jaan de ûndertekener de mooglikheid om te kiezen ien fan ferskate hantekeningen. Yn it gefal fan RSA: "ien ynfierwearde" + "ien kaaipaar" = "ien hantekening". It is ûnmooglik om te foarsizzen hokker hantekening in oare RP sil krije, dus in PVRB mei deterministyske hantekeningen kin wurde organisearre troch it kombinearjen fan de RSA hantekenings fan ferskate dielnimmers dy't tekene deselde wearde. Bygelyks, de foarige willekeurich. Dizze regeling besparret in soad middels, omdat hantekeningen binne sawol befêstiging fan it juste gedrach neffens it protokol as in boarne fan willekeur.

Sels mei deterministyske hantekeningen is it skema lykwols noch kwetsber foar it probleem "lêste akteur". De lêste dielnimmer kin noch beslute om de hantekening te publisearjen of net, en dêrmei de útkomst te kontrolearjen. Jo kinne it skema wizigje, block-hashes tafoegje, rûnen meitsje, sadat it resultaat net fan tefoaren kin wurde foarsizze, mar al dizze techniken, sels mei rekkening fan in protte oanpassingen, litte it probleem fan 'e ynfloed fan ien dielnimmer op it kollektyf noch net oplost. resultearje yn in ûnfertroude omjouwing en kin allinich wurkje ûnder ekonomyske en tiidbeheining. Derneist is de grutte fan RSA-kaaien (1024 en 2048 bits) frij grut, en de grutte foar blockchain-transaksjes is in ekstreem wichtige parameter. Blykber is d'r gjin ienfâldige manier om it probleem op te lossen, lit ús fierder gean.

PVRB en geheime dielingsregelingen

Yn kryptografy binne d'r skema's dy't it netwurk tastean kinne oerienkomme oer ien en mar ien PVRB-wearde, wylst sokke skema's resistint binne foar alle kweade aksjes fan guon dielnimmers. Ien nuttich protokol dat it wurdich is om josels bekend te meitsjen is Shamir's geheime dielenskema. It tsjinnet om te dielen in geheim (Bygelyks, in geheime kaai) yn ferskate dielen, en fersprieden dizze dielen oan N dielnimmers. It geheim wurdt ferdield op sa'n manier dat M dielen út N binne genôch om te herstellen it, en dit kin wêze eltse M dielen. As op fingers, dan mei in grafyk fan in ûnbekende funksje, wikselje de dielnimmers punten op 'e grafyk, en nei ûntfangst fan M punten, kin de hiele funksje wersteld wurde.
In goede útlis wurdt jûn yn wiki mar boartsjen mei it praktysk om te spyljen it protokol yn dyn holle is nuttich foar demo side.

As it FSSS (Fiat-Shamir Secret Sharing) skema yn syn suvere foarm fan tapassing wie, soe it in ûnferwoastbere PVRB wêze. Yn syn ienfâldichste foarm kin it protokol der sa útsjen:

• Elke dielnimmer genereart har eigen willekeurich en dielt oandielen derfan út oan oare dielnimmers
• Elke dielnimmer ûntbleatet syn diel fan 'e geheimen fan' e oare dielnimmers
• As in dielnimmer mear dan M-oandielen hat, dan kin it oantal fan dizze dielnimmer wurde berekkene, en it sil unyk wêze, nettsjinsteande de set fan iepenbiere dielnimmers
• De kombinaasje fan iepenbiere willekeurich is de winske PVRB

Hjir beynfloedet in yndividuele dielnimmer net mear de resultaten fan it protokol, útsein yn gefallen dêr't it berikken fan 'e willekeurich iepenbiering drompel allinnich hinget ôf fan him. Dêrom wurket dit protokol, as d'r in fereaske oanpart fan RP's is dy't oan it protokol wurkje en beskikber is, wurket, ymplemintearret de easken foar kryptografyske sterkte, en is resistint foar it probleem "lêste akteur".

Dit kin in ideale opsje wêze, dit PVRB-skema basearre op Fiat-Shamir geheime dielen wurdt bygelyks beskreaun yn dit lidwurd. Mar, lykas hjirboppe neamd, as jo besykje it op 'e kop te passen yn' e blockchain, ferskine technyske beheiningen. Hjir is in foarbyld fan in test-ymplemintaasje fan it protokol yn it EOS-tûke kontrakt en it wichtichste diel dêrfan - kontrolearjen fan 'e publisearre dielde dielnimmer: code. Jo kinne sjen út de koade dat bewiis falidaasje fereasket ferskate scalar fermannichfâldigjen, en de nûmers brûkt binne hiel grut. It moat begrepen wurde dat yn blockchains ferifikaasje foarkomt op it momint dat de blokprodusint de transaksje ferwurket, en yn 't algemien moat elke dielnimmer de krektens fan it protokol maklik ferifiearje, sadat de easken foar de snelheid fan' e ferifiearjefunksje tige serieus binne . Yn dizze opsje bliek de opsje net effektyf te wêzen, om't de ferifikaasje net paste binnen de transaksjelimyt (0.5 sekonden).

Ferifikaasje-effisjinsje is ien fan 'e wichtichste easken foar it gebrûk fan, yn' t algemien, alle avansearre kryptografyske skema's yn 'e blockchain. Bewizen oanmeitsje, berjochten tariede - dizze prosedueres kinne wurde nommen off-chain en útfierd op hege-optreden kompjûters, mar ferifikaasje kin net omgean - dit is in oare wichtige eask foar PVRB.

PVRB en drompel hântekeningen

Nei't wy kunde wurden binne mei it geheime dielenskema, ûntdutsen wy in heule klasse fan protokollen ferienige troch it kaaiwurd "drompel". Wannear't it iepenbierjen fan guon ynformaasje de dielname fan M earlike dielnimmers út N fereasket, en de set fan earlike dielnimmers kin in willekeurige subset fan N wêze, sprekke wy fan "drompel" -skema's. It binne se dy't ús tastean om te gean mei it probleem "lêste akteur", no as de oanfaller syn diel fan it geheim net iepenbieret, sil in oare, earlike dielnimmer it foar him dwaan. Dizze regelingen jouwe oerienkomst oer ien en ien betsjutting, sels as it protokol troch guon fan 'e dielnimmers sabotearre wurdt.

De kombinaasje fan deterministyske hantekeningen en drompelskema's makke it mooglik om in heul handich en kânsryk skema te ûntwikkeljen foar it útfieren fan PVRB - dit binne deterministyske drompelhantekeningen. Hjir artikel oer de ferskate gebrûk fan drompel hântekeningen, en hjir is in oare goede langlêzen fan Dash.

It lêste artikel beskriuwt BLS-hantekeningen (BLS stiet foar Boneh-Lynn-Shacham, sjoch artikel), dy't in heul wichtige en ekstreem handige kwaliteit hawwe foar programmeurs - iepenbiere, geheime, iepenbiere kaaien en BLS-hântekeningen kinne mei elkoar wurde kombinearre mei ienfâldige wiskundige operaasjes, wylst har kombinaasjes jildige kaaien en hantekeningen bliuwe, wêrtroch jo in protte maklik kinne aggregearje hantekeningen yn ien en in protte iepenbiere kaaien yn ien. Se binne ek deterministysk en produsearje itselde resultaat foar deselde ynfiergegevens. Mei tank oan dizze kwaliteit binne kombinaasjes fan BLS-hântekeningen sels jildige kaaien, wat mooglik makket foar de ymplemintaasje fan in opsje wêryn M fan N-dielnimmers ien en mar ien hantekening produsearje dy't deterministysk, iepenbier ferifieare en ûnfoarspelber is oant it wurdt iepene troch de Mth dielnimmer.

Yn in skema mei drompel BLS hantekenings tekenet eltse dielnimmer wat mei help fan BLS (Bygelyks, de foarige willekeurich), en de mienskiplike drompel hântekening is de winske willekeurich. De kryptografyske eigenskippen fan BLS-hântekeningen befredigje de easken foar willekeurige kwaliteit, it drompeldiel beskermet tsjin "lêste-akteur", en de unike kombinabiliteit fan kaaien makket it mooglik om folle mear nijsgjirrige algoritmen te ymplementearjen dy't bygelyks effisjinte aggregaasje fan protokolberjochten mooglik meitsje. .

Dus, as jo PVRB bouwe op jo blockchain, sille jo nei alle gedachten einigje mei it BLS-drompel-hantekeningskema, ferskate projekten brûke it al. Bygelyks, DFinity (hjir benchmark dat ymplemintearret it circuit, en hjir foarbyld ymplemintaasje fan ferifiearje geheime dielen), of Keep.network (hjir is harren willekeurige beacon giel papieren hjir foarbyld smart kontrakt dat it protokol tsjinnet).

Útfiering fan PVRB

Spitigernôch sjogge wy noch gjin klear makke protokol ymplementearre yn PVRB-blokken dy't har feiligens en stabiliteit bewiisd hat. Ek al binne de protokollen sels klear, se technysk tapassen op besteande oplossingen is net maklik. Foar sintralisearre systemen makket PVRB gjin sin, en desintralisearre wurde strikt beheind yn alle komputerboarnen: CPU, ûnthâld, opslach, I / O. It ûntwerpen fan in PVRB is in kombinaasje fan ferskate protokollen om wat te meitsjen dat foldocht oan alle easken foar op syn minst wat libbensfetbere blockchain. Ien protokol berekkent effisjinter, mar fereasket mear berjochten tusken RPs, wylst de oare fereasket hiel pear berjochten, mar it meitsjen fan in bewiis kin in taak dy't duorret tsientallen minuten, of sels oeren.

Ik sil de faktoaren listje dy't jo moatte beskôgje as jo in kwaliteit PVRB kieze:

• Kryptografyske sterkte. Jo PVRB moat strikt unbiasable wêze, mei gjin mooglikheid om ien bit te kontrolearjen. Yn guon regelingen is dit net it gefal, dus skilje in kryptograaf
• De "lêste akteur" probleem. Jo PVRB moat resistint wêze foar oanfallen wêrby't in oanfaller dy't ien of mear RP's kontrolearje kin ien fan twa útkomsten kieze.
• Protokol sabotaazje probleem. Jo PVRB moat resistint wêze foar oanfallen wêrby't in oanfaller dy't ien of mear RP's kontrolearret, beslút of it willekeurich is of net en kin wurde garandearre of mei in opjûne kâns om dit te beynfloedzjen
• Oantal berjochten probleem. Jo RP's moatte in minimum fan berjochten nei de blockchain stjoere en syngroane aksjes safolle mooglik foarkomme, lykas situaasjes lykas "Ik stjoer wat ynformaasje, ik wachtsje op in antwurd fan in spesifike dielnimmer." Yn p2p-netwurken, benammen geografysk ferspraat, moatte jo net rekkenje op in rappe reaksje
• It probleem fan computational kompleksiteit. Ferifikaasje fan elke faze fan 'e PVRB on-chain moat ekstreem maklik wêze, om't it wurdt útfierd troch alle folsleine kliïnten fan it netwurk. As de ymplemintaasje dien wurdt mei in tûk kontrakt, dan binne de snelheidseasken tige strang
• It probleem fan berikberens en libbenens. Jo PVRB moat stribje om resistint te wêzen foar situaasjes wêr't in diel fan it netwurk foar in perioade fan tiid net beskikber wurdt en in diel fan 'e RP gewoan ophâldt mei wurkjen
• It probleem fan fertroude opset en initial kaaiferdieling. As jo ​​PVRB de primêre opset fan it protokol brûkt, dan is dit in apart grut en serieus ferhaal. Hjir foarbyld. As dielnimmers inoar harren kaaien fertelle moatte foardat it protokol begjint, is dat ek in probleem as de gearstalling fan dielnimmers feroaret
• Untwikkelingsproblemen. Beskikberens fan biblioteken yn 'e fereaske talen, har feiligens en prestaasjes, publisiteit, komplekse tests, ensfh.

Bygelyks, drompel BLS hantekeningen hawwe in wichtich probleem - foardat begjinne te wurkjen, dielnimmers moatte fersprieden kaaien oan elkoar, organisearje in groep binnen hokker drompel sil wurkje. Dit betsjut dat op syn minst ien omloop fan útwikseling yn in desintralisearre netwurk sil moatte wachtsje, en jûn dat de generearre rand, bygelyks, is nedich yn spultsjes, hast yn echte tiid, dit betsjut dat sabotaazje fan it protokol is mooglik op dit stadium , en de foardielen fan it drompelskema geane ferlern. Dit probleem is al ienfâldiger as de foargeande, mar fereasket noch de ûntwikkeling fan in aparte proseduere foar de foarming fan drompelgroepen, dy't ekonomysk beskerme wurde moatte, troch depots en weromlûken fan fûnsen (slashing) fan dielnimmers dy't de dielnimmers net folgje protokol. Ek BLS-ferifikaasje mei in akseptabel nivo fan feiligens past gewoan net, bygelyks, yn in standert EOS- of Ethereum-transaksje - d'r is gewoan net genôch tiid foar ferifikaasje. De kontraktkoade is WebAssembly of EVM, útfierd troch in firtuele masine. Kryptografyske funksjes wurde (noch) net native ymplemintearre, en wurkje tsientallen kearen stadiger as konvinsjonele kryptografyske bibleteken. In protte protokollen foldogge net oan de easken gewoan basearre op kaai folume, bygelyks 1024 en 2048 bits foar RSA, 4-8 kear grutter as de standert transaksje hântekening yn Bitcoin en Ethereum.

De oanwêzigens fan ymplemintaasjes yn ferskate programmeartalen spilet ek in rol - wêrfan d'r in pear binne, foaral foar nije protokollen. De opsje mei yntegraasje yn konsensus fereasket it skriuwen fan in protokol yn 'e platfoarmtaal, dus jo moatte sykje nei koade yn Go for geth, yn Rust for Parity, yn C ++ foar EOS. Elkenien sil nei JavaScript-koade moatte sykje, en om't JavaSkript en kryptografy net bysûnder nauwe freonen binne, sil WebAssembly helpe, dy't no definityf beweart de folgjende wichtige ynternetstandert te wêzen.

konklúzje

Ik hoopje yn 'e foarige artikel Ik slagge jo te oertsjûgjen dat it generearjen fan willekeurige nûmers op 'e blockchain kritysk is foar in protte aspekten fan it libben fan desintralisearre netwurken, en mei dit artikel liet ik sjen dat dizze taak ekstreem ambisjeus en dreech is, mar goede oplossingen besteane al. Yn 't algemien is it definitive ûntwerp fan it protokol allinich mooglik nei it útfieren fan massive tests dy't rekken hâlde mei alle aspekten fan opset oant foutemulaasje, dus it is net wierskynlik dat jo klearmakke resepten sille fine yn team whitepapers en artikels, en wy sille wis net beslute yn it folgjende jier as twa skriuwe "do it op dizze manier, krekt goed."

Bye, foar ús PVRB yn 'e blockchain wurdt ûntwikkele haya, Wy hawwe fêstlein op it brûken fan drompel BLS-hantekeningen, wy binne fan plan om PVRB op konsensusnivo út te fieren, om't ferifikaasje yn tûke kontrakten mei in akseptabel nivo fan feiligens noch net mooglik is. It is mooglik dat wy twa skema's tagelyk brûke: earst, djoere geheime dielen foar it meitsjen fan lange termyn random_seed, en dan brûke wy it as basis foar willekeurige generaasje mei hege frekwinsje mei deterministyske drompel BLS-hantekeningen, miskien sille wy ússels beheine ta allinich ien fan 'e regelingen. Spitigernôch is it ûnmooglik om fan tefoaren te sizzen wat it protokol sil wêze; it ienige goede ding is dat, lykas yn 'e wittenskip, yn technyske problemen, ek in negatyf resultaat is, en elke nije besykjen om it probleem op te lossen is in oare stap foar it ûndersyk fan elkenien belutsen by it probleem. Om oan saaklike easken te foldwaan, losse wy in spesifyk praktysk probleem op - it leverjen fan gamingapplikaasjes mei in betroubere boarne fan entropy, dus wy moatte ek omtinken jaan oan 'e blockchain sels, yn' t bysûnder de problemen fan ketenfinaliteit en netwurkbestjoer.

En ek al sjogge wy noch gjin bewiisde resistinte PVRB yn blokken, dy't genôch tiid brûkt wurde soe om te testen troch echte applikaasjes, meardere audits, loads, en fansels echte oanfallen, mar it oantal mooglike paden befêstiget dat in oplossing bestiet, en wat -fan dizze algoritmen sille úteinlik oplosse it probleem. Wy sille bliid wêze om de resultaten te dielen en oare teams te tankjen dy't ek oan dit probleem wurkje foar artikels en koade wêrmei yngenieurs net twa kear op deselde rake stappe kinne.

Dat, as jo in programmeur moetsje dy't desintralisearre willekeurich ûntwerpt, wês dan oandachtich en soarchsume, en leverje psychologyske help as nedich :)

Boarne: www.habr.com