Inngangur

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

Eins og með hugmyndina um algerlega sterkt dulmál úr dulkóðun, reyna raunverulegar „Opinberlega sannanlegar slembiljós“ (hér eftir PVRB) samskiptareglur aðeins að komast eins nálægt hinu fullkomna kerfi og mögulegt er, vegna þess að í raunverulegum netum á það ekki við í sinni hreinu mynd: það er nauðsynlegt að samþykkja nákvæmlega einn bita, það verða að vera margar umferðir og öll skilaboð verða að vera fullkomlega hröð og alltaf afhent. Auðvitað er þetta ekki raunin í raunverulegum netum. Þess vegna, þegar hannað er PVRB fyrir tiltekin verkefni í nútíma blokkkeðjum, auk þess að ómögulegt er að stjórna tilviljuninni og dulritunarstyrknum, sem myndast, koma upp mörg fleiri eingöngu byggingarfræðileg og tæknileg vandamál.

Fyrir PVRB er blockchain sjálft í raun samskiptamiðill þar sem skilaboð = viðskipti. Þetta gerir þér kleift að draga úr netvandamálum að hluta, ekki afhenda skilaboð, vandamál með millihugbúnað - allar þessar áhættur eru teknar af dreifða netkerfinu og aðalgildi þess fyrir PVRB er vanhæfni til að afturkalla eða skemma þegar send viðskipti - þetta gerir ekki leyfa þátttakendum að neita að taka þátt í bókuninni, nema þeir hafi gert árangursríka árás á samstöðu. Þetta öryggisstig er ásættanlegt, þannig að PVRB ætti að vera ónæmur fyrir samráði þátttakenda í nákvæmlega sama mæli og aðal blockchain keðjan. Þetta gefur líka til kynna að PVRB verði að vera hluti af samstöðunni ef netið er sammála um aðal blokkarkeðjuna, jafnvel þótt það sé einnig sammála um eina sanngjarna af handahófi. Eða, PVRB er einfaldlega sjálfstæð samskiptaregla útfærð með snjöllum samningi sem virkar ósamstilltur með tilliti til blockchain og blokka. Báðar aðferðirnar hafa sína kosti og galla og valið á milli þeirra er ákaflega lítið.

Tvær leiðir til að innleiða PVRB

Leyfðu okkur að lýsa nánar tveimur valkostum til að innleiða PVRB - sjálfstæðu útgáfuna, sem virkar með því að nota snjallsamning óháð blockchain, og samþætt útgáfa, innbyggð í siðareglur, samkvæmt henni er netið sammála um blockchain og viðskipti sem eiga að vera með. Í öllum tilfellum mun ég meina vinsælar blockchain vélar: Ethereum, EOS og alla þá sem líkjast þeim hvernig þeir hýsa og vinna úr snjöllum samningum.

Sjálfstæður samningur

Í þessari útgáfu er PVRB snjall samningur sem tekur við viðskiptum tilviljunarkenndra framleiðenda (hér eftir nefnt RP), vinnur úr þeim, sameinar niðurstöðurnar og, þar af leiðandi, fær ákveðið gildi sem allir notendur geta fengið frá þessum samningi. Þetta gildi má ekki geyma beint í samningnum, heldur er það aðeins táknað með gögnum þar sem hægt er að fá eitt og aðeins eitt gildi af handahófinu sem myndast með ákveðnum hætti. Í þessu kerfi eru RP notendur blockchain og allir geta fengið að taka þátt í kynslóðarferlinu.

Valkosturinn með sjálfstæðum samningi er góður:

• flytjanleiki (hægt er að draga samninga frá blockchain til blockchain)
• auðveld útfærsla og prófun (auðvelt er að skrifa og prófa samninga)
• þægindi við innleiðingu efnahagslegra kerfa (auðvelt er að búa til eigin tákn, þar sem rökfræði þjónar tilgangi PVRB)
• möguleiki á að ræsa blockchains sem þegar eru í gangi

Það hefur einnig ókosti:

• sterkar takmarkanir á tölvuauðlindum, færslumagni og geymslu (með öðrum orðum, CPU/mem/io)
• takmarkanir á starfsemi innan samningsins (ekki eru allar leiðbeiningar tiltækar, erfitt er að tengja utanaðkomandi bókasöfn)
• vanhæfni til að skipuleggja skilaboð hraðar en viðskipti eru innifalin í blockchain

Þessi valkostur er hentugur til að útfæra PVRB sem þarf að keyra á núverandi neti, inniheldur ekki flókna dulritun og krefst ekki mikils fjölda samskipta.

Samþætt

Í þessari útgáfu er PVRB útfært í blockchain hnútkóðann, innbyggður eða keyrður samhliða skilaboðaskiptum milli blockchain hnúta. Niðurstöður samskiptareglunnar eru skrifaðar beint inn í framleiddu blokkirnar og samskiptaskilaboð eru send yfir p2p netið á milli hnúta. Þar sem samskiptareglan leiðir af sér tölur sem á að skrifa í blokkum verður netið að ná samstöðu um þær. Þetta þýðir að PVRB skilaboð, eins og viðskipti, verða að vera staðfest af hnútum og innifalin í blokkum svo að allir netþátttakendur geti staðfest samræmi við PVRB samskiptareglur. Þetta leiðir okkur sjálfkrafa að augljósu lausninni - ef netið er sammála um samstöðu um blokk og viðskipti í henni, þá ætti PVRB að vera hluti af samstöðunni, en ekki sjálfstæð siðareglur. Annars er mögulegt að blokk sé gild frá samstöðu sjónarhorni, en PVRB siðareglur er ekki fylgt og frá PVRB sjónarhóli er ekki hægt að samþykkja blokkina. Þannig að ef „samþættur“ valkosturinn er valinn, verður PVRB mikilvægur hluti af samstöðunni.

Þegar PVRB útfærslum er lýst á samstöðustigi netsins er ekki með neinum hætti hægt að komast hjá endanleikamálum. Endanleiki er vélbúnaður sem notaður er í ákveðinni samstöðu sem læsir blokk (og keðjuna sem leiðir að henni) sem er endanlegur og verður aldrei hent, jafnvel þó að samhliða gaffli verði. Til dæmis, í Bitcoin er ekkert slíkt fyrirkomulag - ef þú birtir keðju sem er flóknari, mun hún koma í stað allra minna flókinna, óháð lengd keðjanna. Og í EOS, til dæmis, eru þær síðustu hinar svokölluðu Last Irversible Blocks, sem birtast að meðaltali á 432 kubba fresti (12*21 + 12*15, pre-vote + pre-commit). Þetta ferli bíður í raun eftir 2/3 af blokkframleiðendum (hér eftir nefnt BP) undirskriftar. Þegar gafflar birtast sem eru eldri en síðasta LIB er þeim einfaldlega hent. Þetta fyrirkomulag gerir það mögulegt að tryggja að viðskiptin séu innifalin í blockchain og verði aldrei afturkölluð, sama hvaða úrræði árásarmaðurinn hefur. Einnig eru lokablokkirnar blokkir undirritaðar af 2/3 BP í Hyperledger, Tendermint og öðrum pBFT-undirstaða samstöðu. Einnig er skynsamlegt að gera siðareglur til að tryggja endanleika sem viðbót við samstöðu, þar sem hún getur virkað ósamstillt við framleiðslu og útgáfu blokka. Hér er einn góður grein um endanleika í Ethereum.

Endanleiki er gríðarlega mikilvægur fyrir notendur, sem án þess gætu lent í „tvöfaldri eyðslu“ árás, þar sem BP „heldur“ blokkum og birtir þær eftir að netið hefur „séð“ góð viðskipti. Ef það er engin endanleiki, þá kemur út gaffalinn í stað blokkarinnar fyrir „góð“ viðskipti við annan, frá „slæmri“ gaffli, þar sem sömu fjármunir eru fluttir á heimilisfang árásarmannsins. Þegar um PVRB er að ræða eru kröfurnar um endanleika enn strangari, þar sem að byggja gaffla fyrir PVRB þýðir tækifæri fyrir árásarmann til að undirbúa nokkra handahófskennda valkosti til að birta þann arðbærasta og takmarka tíma mögulegrar árásar er góð lausn.

Þess vegna er besti kosturinn að sameina PVRB og endanleika í eina siðareglur - þá endanlega blokkin = endanlega af handahófi, og þetta er nákvæmlega það sem við þurftum að fá. Nú munu leikmenn fá tryggt handahóf á N sekúndum og geta verið vissir um að það sé ómögulegt að snúa því til baka eða spila það aftur.

Samþætti valkosturinn er góður:

• möguleiki á ósamstilltri útfærslu í tengslum við framleiðslu á blokkum - blokkir eru framleiddar eins og venjulega, en samhliða þessu getur PVRB siðareglur virkað, sem framleiðir ekki tilviljun fyrir hverja blokk
• getu til að innleiða jafnvel þunga dulritun, án takmarkana sem settar eru á snjalla samninga
• getu til að skipuleggja skilaboðaskipti hraðar en viðskipti eru innifalin í blockchain, til dæmis getur hluti af samskiptareglunni virkað á milli hnúta án þess að dreifa skilaboðum yfir netið

Það hefur einnig ókosti:

• Erfiðleikar við prófun og þróun - þú verður að líkja eftir netvillum, hnútum sem vantar, harða gaffla á neti
• Innleiðingarvillur krefjast netkerfis

Báðar aðferðir við að innleiða PVRB eiga rétt á lífi, en innleiðing á snjöllum samningum í nútíma blokkkeðjum er enn frekar takmörkuð í tölvuauðlindum og öll umskipti yfir í alvarlega dulritun er oft einfaldlega ómöguleg. Og við munum þurfa alvarlega dulritun, eins og sýnt verður hér að neðan. Þrátt fyrir að þetta vandamál sé greinilega tímabundið, þarf alvarlega dulritun í samningum til að leysa mörg vandamál og það er smám saman að birtast (til dæmis kerfissamningar fyrir zkSNARKs í Ethereum)

Blockchain, sem veitir gagnsæja og áreiðanlega samskiptaboðarás, gerir það ekki ókeypis. Allar dreifðar samskiptareglur verða að taka tillit til möguleika á Sybil árás; allar aðgerðir geta verið gerðar af samstilltum herafla margra reikninga, þess vegna er nauðsynlegt, þegar hannað er, að taka tillit til getu árásarmanna til að búa til handahófskenndan fjölda samskiptareglur þátttakendur sem starfa í samráði.

PVRB og blokkarbreytur.

Ég laug ekki þegar ég sagði að enginn hefur enn innleitt gott PVRB, prófað af mörgum fjárhættuspilaforritum, í blockchains. Hvaðan koma þá svona mörg fjárhættuspil á Ethereum og EOS? Þetta kemur mér jafn mikið á óvart og það kemur þér á óvart, hvar fengu þeir svona mikið af „viðvarandi“ tilviljun í algjörlega ákveðnu umhverfi?

Uppáhalds leiðin til að fá tilviljun í blockchain er að taka einhvers konar „óútreiknanlegar“ upplýsingar úr blokkinni og búa til handahófskenndar út frá þeim - einfaldlega með því að hassa eitt eða fleiri gildi. Góð grein um vandamál slíkra kerfa hér. Þú getur tekið hvaða „óútreiknanlegu“ gildi sem er í blokkinni, til dæmis blokkarhash, fjölda viðskipta, flókið netkerfi og önnur gildi sem eru þekkt fyrirfram. Þá hash þá, einn eða fleiri, og í orði, þú ættir að fá alvöru handahófi. Þú getur jafnvel bætt því við blaðið að kerfið þitt sé „eftir skammtaöryggi“ (þar sem það eru skammtaþéttar kjötkássaaðgerðir :)).

En jafnvel öruggur kjötkássa eftir skammtafræði er ekki nóg, því miður. Leyndarmálið liggur í kröfunum til PVRB, ég minni þig á þær úr fyrri grein:

1. Niðurstaðan verður að hafa sannanlega einsleita dreifingu, þ.e.a.s. byggjast á sannanlega sterkri dulritun.
2. Það er ekki hægt að stjórna neinum bitum niðurstöðunnar. Þar af leiðandi er ekki hægt að spá fyrir um niðurstöðuna fyrirfram.
3. Þú getur ekki spillt samskiptareglunum með því að taka ekki þátt í samskiptareglunum eða með því að ofhlaða netið með árásarskilaboðum
4. Allt ofangreint verður að vera ónæmt fyrir samráði leyfilegs fjölda óheiðarlegra þátttakenda (til dæmis 1/3 þátttakenda).

Í þessu tilviki er aðeins kröfu 1 uppfyllt og kröfu 2 er ekki uppfyllt. Með því að hassa ófyrirsjáanleg gildi úr blokkinni fáum við samræmda dreifingu og góða tilviljun. En BP hefur að minnsta kosti möguleika á að „birta blokkina eða ekki“. Þannig getur BP að minnsta kosti valið úr TVEIMUM tilviljunarkenndum valkostum: „sín eigin“ og sá sem kemur í ljós ef einhver annar gerir blokkina. BP getur "snoopað" fyrirfram hvað mun gerast ef hann birtir blokk og ákveður einfaldlega að gera það eða ekki. Þannig að þegar hann spilar til dæmis „sléttu“ eða „rautt/svart“ í rúlletta getur hann aðeins birt blokk ef hann sér vinning. Þetta gerir líka þá aðferð að nota til dæmis blokkahash „frá framtíðinni“ óframkvæmanleg. Í þessu tilviki segja þeir að „handahófi verður notað, sem fæst með því að hassa núverandi gögn og kjötkássa framtíðarblokkar með hæðina til dæmis N + 42, þar sem N er núverandi blokkarhæð. Þetta styrkir kerfið aðeins, en leyfir samt BP, að vísu í framtíðinni, að velja hvort það eigi að halda blokkinni eða gefa út.

BP hugbúnaður í þessu tilfelli verður flóknari, en ekki mikið. Einfaldlega, þegar færslur eru staðfestar og teknar með í blokk, er fljótlegt athugað til að sjá hvort vinningur verði, og hugsanlega val á einum færslubreytum til að fá miklar líkur á vinningi. Á sama tíma er næstum ómögulegt að ná snjöllum BP fyrir slíkar aðgerðir; í hvert skipti geturðu notað ný heimilisföng og unnið smátt og smátt án þess að vekja grunsemdir.

Þannig að aðferðir sem nota upplýsingar úr blokkinni henta ekki sem alhliða útfærsla á PVRB. Í takmarkaðri útgáfu, með takmörkunum á veðmálsstærðum, takmörkunum á fjölda leikmanna og/eða KYC skráningu (til að koma í veg fyrir að einn leikmaður noti mörg heimilisföng), geta þessi kerfi virkað fyrir litla leiki, en ekkert meira.

PVRB og skuldbinda-afhjúpun.

Allt í lagi, þökk sé kjötkássa og að minnsta kosti hlutfallslegan ófyrirsjáanleika blokkkásssins og annarra breyta. Ef þú leysir vandamál fremstu námuverkamanna ættirðu að fá eitthvað hentugra. Bætum notendum við þetta kerfi - leyfum þeim líka að hafa áhrif á handahófið: allir starfsmenn tækniaðstoðar munu segja þér að það sem er mest tilviljunarkennt í upplýsingatæknikerfum eru aðgerðir notenda :)

Barnlaust kerfi, þegar notendur senda einfaldlega tilviljunarkenndar tölur og niðurstaðan er reiknuð sem til dæmis kjötkássa af summu þeirra, hentar ekki. Í þessu tilviki getur síðasti leikmaðurinn, með því að velja sitt eigið handahóf, stjórnað hver niðurstaðan verður. Þetta er ástæðan fyrir því að hið mjög mikið notaða commit-reveal mynstur er notað. Þátttakendur senda fyrst kjötkássa úr tilviljunarkenndum sínum (commits) og opna síðan sjálfir (reveals). „Afhjúpunarfasinn“ hefst aðeins eftir að nauðsynlegum skuldbindingum hefur verið safnað, þannig að þátttakendur geta sent nákvæmlega tilviljunarkenndan kjötkássa sem þeir sendu áður. Nú skulum við setja allt þetta saman við færibreytur blokkar, og betra en einn sem er tekinn úr framtíðinni (tilviljun er aðeins að finna í einum af framtíðarblokkunum), og voila - tilviljunin er tilbúin! Nú hefur hvaða leikmaður sem er áhrif á handahófið sem leiðir af sér og getur „sigrað“ illgjarnan BP með því að hnekkja honum með sínu eigin, fyrirfram óþekktu, handahófi... Þú getur líka bætt við vörn gegn skemmdarverkum á samskiptareglunum með því að opna hana ekki á birtingarstigi - einfaldlega með því að krefjast þess að ákveðin upphæð fylgi viðskiptunum við skuldbindingu — tryggingagjald, sem verður aðeins skilað meðan á afhjúpunarferlinu stendur. Í þessu tilviki mun það vera gagnslaust að skuldbinda sig og láta ekki í ljós.

Þetta var góð tilraun og slík kerfi eru líka til í DApps leikja, en því miður er þetta ekki nóg. Nú getur ekki aðeins námumaðurinn, heldur einnig allir þátttakendur í bókuninni, haft áhrif á niðurstöðuna. Það er samt hægt að stjórna verðmætinu sjálfu, með minni breytileika og með kostnaði, en, eins og í tilviki námumannsins, ef niðurstöður teikningarinnar eru verðmætari en gjaldið fyrir þátttöku í PVRB samskiptareglunum, þá er tilviljunarkennd -framleiðandi(RP) getur ákveðið hvort hann eigi að sýna og getur samt valið úr að minnsta kosti tveimur tilviljunarkenndum valkostum.
En það varð hægt að refsa þeim sem skuldbinda sig og láta ekki í ljós, og þetta kerfi mun koma sér vel. Einfaldleiki þess er alvarlegur kostur - alvarlegri samskiptareglur krefjast mun öflugri útreikninga.

PVRB og deterministic undirskriftir.

Það er önnur leið til að þvinga RP til að gefa upp gervi-handahófskennda tölu sem það getur ekki haft áhrif á ef það er búið „formynd“ - þetta er ákveðin undirskrift. Slík undirskrift er til dæmis RSA og er ekki ECS. Ef RP er með lyklapar: RSA og ECC, og hann skrifar undir ákveðið gildi með einkalyklinum sínum, þá fær hann EINA OG AÐEINS EINA undirskrift, ef um RSA er að ræða, og ef um ECS er að ræða getur hann búið til hvaða fjölda sem er af mismunandi gildar undirskriftir. Þetta er vegna þess að þegar ECS undirskrift er búin til er notast við handahófskennd númer, valin af undirritara, og er hægt að velja hana á hvaða hátt sem er, sem gefur undirritaða tækifæri til að velja eina af nokkrum undirskriftum. Í tilviki RSA: „eitt inntaksgildi“ + „eitt lyklapar“ = „ein undirskrift“. Það er ómögulegt að spá fyrir um hvaða undirskrift annar RP mun fá, þannig að hægt er að skipuleggja PVRB með ákveðinni undirskrift með því að sameina RSA undirskrift nokkurra þátttakenda sem skrifuðu undir sama gildi. Til dæmis, fyrri handahófi. Þetta fyrirkomulag sparar mikið fjármagn, vegna þess Undirskriftir eru bæði staðfesting á réttri hegðun samkvæmt siðareglum og uppspretta handahófs.

Hins vegar, jafnvel með ákveðinn undirskrift, er kerfið enn viðkvæmt fyrir „síðasta leikara“ vandamálinu. Síðasti þátttakandi getur samt ákveðið hvort hann birti undirskriftina eða ekki og stjórnar þar með niðurstöðunni. Þú getur breytt kerfinu, bætt við kubba kjötkássa við það, gert umferðir þannig að ekki sé hægt að spá fyrir um niðurstöðuna fyrirfram, en allar þessar aðferðir, jafnvel að teknu tilliti til margra breytinga, skilja enn eftir óleyst vandamálið um áhrif eins þátttakanda á hópinn. leiða af sér ótraust umhverfi og getur aðeins starfað undir efnahags- og tímatakmörkunum. Að auki er stærð RSA lykla (1024 og 2048 bita) nokkuð stór og stærðin fyrir blockchain viðskipti er afar mikilvæg færibreyta. Það er greinilega engin einföld leið til að leysa vandamálið, við skulum halda áfram.

PVRB og leyndarsamnýtingarkerfi

Í dulmáli eru til kerfi sem geta gert netkerfinu kleift að koma sér saman um eitt og aðeins eitt PVRB gildi, á meðan slík kerfi eru ónæm fyrir illgjarnum aðgerðum sumra þátttakenda. Ein gagnleg siðareglur sem vert er að kynna sér er leyndarmál deilingarkerfi Shamirs. Það þjónar til að skipta leyndarmáli (til dæmis leynilykli) í nokkra hluta og dreifa þessum hlutum til N þátttakenda. Leyndarmálinu er dreift þannig að M hlutar úr N duga til að endurheimta það og þetta geta verið hvaða M hlutar sem er. Ef á fingrum, þá með línurit af óþekktu falli, skiptast þátttakendur stigum á línuritinu og eftir að hafa fengið M stig er hægt að endurheimta alla fallið.
Góð skýring er gefin í Wiki en að leika með það nánast til að spila samskiptareglur í höfðinu á þér er gagnlegt fyrir kynningu síðu.

Ef FSSS (Fiat-Shamir Secret Sharing) kerfið ætti við í sinni hreinu mynd, væri það óslítandi PVRB. Í sinni einföldustu mynd gæti samskiptareglan litið svona út:

• Hver þátttakandi býr til sinn eigin handahófi og dreifir hlutum úr því til annarra þátttakenda
• Hver þátttakandi opinberar sinn hluta af leyndarmálum hinna þátttakendanna
• Ef þátttakandi á fleiri en M hluti, þá er hægt að reikna út fjölda þessa þátttakanda og hann verður einstakur, óháð hópi opinberra þátttakenda
• Samsetningin af afhjúpuðu tilviljun er æskileg PVRB

Hér hefur einstakur þátttakandi ekki lengur áhrif á niðurstöður bókunarinnar, nema í þeim tilvikum þar sem uppfylling viðmiðunarmörks tilviljunarkenndar er einungis háð honum. Þess vegna virkar þessi siðareglur, ef það er tilskilið hlutfall RPs sem vinna að samskiptareglunum og eru tiltækar, virkar, innleiðir kröfur um dulritunarstyrk og er ónæmur fyrir „síðasta leikara“ vandamálinu.

Þetta gæti verið tilvalinn kostur, þessu PVRB kerfi byggt á Fiat-Shamir leyndarmáli er lýst til dæmis í þetta grein. En eins og getið er hér að ofan, ef þú reynir að beita því beint í blockchain, birtast tæknilegar takmarkanir. Hér er dæmi um prufuútfærslu á samskiptareglunum í EOS snjallsamningnum og mikilvægasti hluti hans - að athuga birtan hlut þátttakanda: kóða. Þú getur séð af kóðanum að sannprófun krefst nokkurra kvarðamarföldunar og tölurnar sem notaðar eru eru mjög stórar. Það ætti að skilja að í blokkkeðjum á sér stað sannprófun á því augnabliki þegar blokkaframleiðandinn vinnur viðskiptin og almennt verður hver þátttakandi auðveldlega að sannreyna réttmæti samskiptareglunnar, svo kröfurnar um hraða sannprófunaraðgerðarinnar eru mjög alvarlegar . Í þessum valkosti reyndist valmöguleikinn árangurslaus þar sem staðfestingin passaði ekki innan viðskiptamarka (0.5 sekúndur).

Skilvirkni sannprófunar er ein mikilvægasta krafan fyrir notkun á, almennt, hvaða háþróaða dulritunarkerfum í blockchain. Að búa til sannanir, útbúa skilaboð - hægt er að taka þessar aðgerðir utan keðju og framkvæma á afkastamiklum tölvum, en ekki er hægt að komast framhjá sannprófun - þetta er önnur mikilvæg krafa fyrir PVRB.

PVRB og þröskuldar undirskriftir

Eftir að hafa kynnst leyndarmálsmiðlunarkerfinu uppgötvuðum við heilan flokk af samskiptareglum sem sameinast er með lykilorðinu „þröskuldur“. Þegar birting sumra upplýsinga krefst þátttöku M heiðarlegra þátttakenda úr N, og mengi heiðarlegra þátttakenda getur verið handahófskenndur hlutmengi N, tölum við um „þröskuld“ kerfi. Það eru þeir sem leyfa okkur að takast á við „síðasta leikarann“ vandamálið, ef árásarmaðurinn opinberar ekki sinn hluta leyndarmálsins mun annar, heiðarlegur þátttakandi gera það fyrir hann. Þessi áætlanir leyfa samkomulagi um eina og eina merkingu, jafnvel þótt samskiptareglan sé skemmd af sumum þátttakendanna.

Sambland af ákveðinni undirskriftum og þröskuldskerfi gerði það mögulegt að þróa mjög þægilegt og efnilegt kerfi til að innleiða PVRB - þetta eru ákveðin þröskuldsmerki. Hérna grein um hina ýmsu notkun þröskulda undirskrifta, og hér er önnur góð longread frá Dash.

Síðasta greinin lýsir BLS undirskriftum (BLS stendur fyrir Boneh-Lynn-Shacham, hér grein), sem hafa mjög mikilvæg og afar þægileg gæði fyrir forritara - hægt er að sameina opinbera, leynilega, opinbera lykla og BLS undirskriftir innbyrðis með einföldum stærðfræðilegum aðgerðum, á meðan samsetningar þeirra eru áfram gildar lyklar og undirskriftir, sem gerir þér kleift að safna saman mörgum auðveldlega. undirskriftir í einn og marga opinbera lykla í einn. Þau eru líka ákveðin og gefa sömu niðurstöðu fyrir sömu inntaksgögn. Þökk sé þessum gæðum eru samsetningar af BLS undirskriftum sjálfir gildar lyklar, sem gerir kleift að útfæra valmöguleika þar sem M af N þátttakendum framleiðir eina og eina undirskrift sem er ákveðin, opinberlega sannreynanleg og ófyrirsjáanleg þar til hún er opnuð af Mth. þátttakandi.

Í kerfi með þröskuld BLS undirskrift undirritar hver þátttakandi eitthvað með því að nota BLS (til dæmis fyrra handahófi), og sameiginlega þröskuldsundirskriftin er æskileg handahófi. Dulritunareiginleikar BLS undirskrifta fullnægja kröfum um tilviljunarkennd gæði, þröskuldshlutinn verndar gegn „last-actor“ og einstök samsetning lykla gerir það mögulegt að innleiða mörg áhugaverðari reiknirit sem leyfa til dæmis skilvirka samsöfnun samskiptaboða. .

Svo, ef þú ert að byggja PVRB á blockchain þinni, muntu líklega enda með BLS þröskuld undirskriftarkerfi, nokkur verkefni eru nú þegar að nota það. Til dæmis, DFinity (hér viðmið sem útfærir hringrásina, og hér dæmi um útfærslu á sannanlegum leyndarmálsdeilingu), eða Keep.network (hér er handahófskennd leiðarljós þeirra gulan pappír, En Dæmi snjall samningur sem þjónar samskiptareglunum).

Innleiðing PVRB

Því miður sjáum við enn ekki tilbúna siðareglur innleidda í PVRB blokkakeðjur sem hefur sannað öryggi sitt og stöðugleika. Jafnvel þó að samskiptareglurnar sjálfar séu tilbúnar er tæknilega ekki auðvelt að beita þeim á núverandi lausnir. Fyrir miðstýrð kerfi er PVRB ekki skynsamlegt og dreifð kerfi eru stranglega takmörkuð í öllum tölvuauðlindum: CPU, minni, geymslu, I/O. Að hanna PVRB er sambland af mismunandi samskiptareglum til að búa til eitthvað sem uppfyllir allar kröfur um að minnsta kosti einhverja raunhæfa blockchain. Önnur samskiptareglan reiknar á skilvirkari hátt, en krefst fleiri skilaboða á milli RPs, á meðan hin krefst mjög fára skilaboða, en að búa til sönnun getur verið verkefni sem tekur tugi mínútna, eða jafnvel klukkustundir.

Ég mun skrá þá þætti sem þú verður að hafa í huga þegar þú velur gæða PVRB:

• Dulritunarstyrkur. PVRB þinn verður að vera algjörlega óhlutdræg, með enga getu til að stjórna einum bita. Í sumum kerfum er þetta ekki raunin, svo hringdu í dulmálsfræðing
• „Síðasti leikarinn“ vandamálið. PVRB þinn verður að vera ónæmur fyrir árásum þar sem árásarmaður sem stjórnar einum eða fleiri RP getur valið eina af tveimur niðurstöðum.
• Skemmdarverkavandamál við bókun. PVRB þinn verður að vera ónæmur fyrir árásum þar sem árásarmaður sem stjórnar einum eða fleiri RPs ákveður hvort hann sé tilviljunarkenndur eða ekki og getur annað hvort verið tryggt eða með tilteknar líkur á að hafa áhrif á þetta
• Fjöldi skilaboða vandamál. RPs þínir ættu að senda að lágmarki skilaboð til blockchain og forðast samstilltar aðgerðir eins mikið og mögulegt er eins og aðstæður eins og "Ég sendi nokkrar upplýsingar, ég er að bíða eftir svari frá tilteknum þátttakanda." Í p2p netum, sérstaklega landfræðilega dreifðum, ættir þú ekki að treysta á skjót viðbrögð
• Vandamálið við flókið reiknikerfi. Staðfesting á hvaða stigi sem er í PVRB-keðjunni ætti að vera mjög auðveld, þar sem það er framkvæmt af öllum fulltrúum netkerfisins. Ef innleiðingin er gerð með snjöllum samningi, þá eru hraðakröfur mjög strangar
• Vandamálið um aðgengi og lífleika. PVRB þinn ætti að leitast við að vera seigur í aðstæðum þar sem hluti netkerfisins verður ófáanlegur í ákveðinn tíma og hluti af RP hættir einfaldlega að virka
• Vandamálið við trausta uppsetningu og upphafslykladreifingu. Ef PVRB þinn notar aðaluppsetningu samskiptareglunnar, þá er þetta sérstök stór og alvarleg saga. Hérna Dæmi. Ef þátttakendur verða að segja hver öðrum frá lyklum sínum áður en þeir hefja siðareglur er það einnig vandamál ef samsetning þátttakenda breytist
• Þróunarvandamál. Aðgengi bókasafna á tilskildum tungumálum, öryggi þeirra og frammistaða, kynning, flókin próf osfrv.

Til dæmis, þröskuldar BLS undirskriftir hafa verulegt vandamál - áður en byrjað er að vinna, verða þátttakendur að dreifa lyklum sín á milli og skipuleggja hóp þar sem þröskuldurinn mun virka. Þetta þýðir að að minnsta kosti ein umferð skipti í dreifðu neti verður að bíða, og í ljósi þess að myndaður rand, til dæmis, er nauðsynlegur í leikjum, næstum í rauntíma, þýðir þetta að skemmdarverk á samskiptareglunum er mögulegt á þessu stigi , og kostir þröskuldskerfisins glatast. Þetta vandamál er nú þegar einfaldara en þau fyrri, en krefst samt þróunar sérstakrar aðferðar til að mynda þröskuldshópa, sem verður að vernda efnahagslega, með innlánum og úttekt fjármuna (slashing) frá þátttakendum sem ekki fylgja siðareglur. Einnig, BLS sannprófun með viðunandi öryggisstigi passar einfaldlega ekki, til dæmis, í staðlaða EOS eða Ethereum viðskipti - það er einfaldlega ekki nægur tími til sannprófunar. Samningskóðinn er WebAssembly eða EVM, keyrður af sýndarvél. Dulmálsaðgerðir eru ekki innleiddar (ennþá) og virka tugfalt hægar en hefðbundin dulmálssöfn. Margar samskiptareglur uppfylla ekki kröfurnar einfaldlega byggðar á lykilmagni, til dæmis 1024 og 2048 bita fyrir RSA, 4-8 sinnum stærri en venjuleg viðskiptaundirskrift í Bitcoin og Ethereum.

Tilvist útfærslur á mismunandi forritunarmálum gegnir einnig hlutverki - sem eru fáir, sérstaklega fyrir nýjar samskiptareglur. Valkosturinn með samþættingu í samstöðu krefst þess að skrifa siðareglur á vettvangsmálinu, svo þú verður að leita að kóða í Go for geth, í Rust for Parity, í C++ fyrir EOS. Allir verða að leita að JavaScript kóða og þar sem JavaScript og dulmál eru ekki sérstaklega nánir vinir mun WebAssembly hjálpa, sem nú segist örugglega vera næsti mikilvægi internetstaðallinn.

Ályktun

Ég vona í fyrri grein Mér tókst að sannfæra þig um að það að búa til handahófskenndar tölur á blockchain er mikilvægt fyrir marga þætti í lífi dreifðra neta og með þessari grein sýndi ég að þetta verkefni er afar metnaðarfullt og erfitt, en góðar lausnir eru þegar til. Almennt séð er lokahönnun samskiptareglunnar aðeins möguleg eftir að hafa framkvæmt umfangsmiklar prófanir sem taka tillit til allra þátta frá uppsetningu til bilanalíkingar, svo það er ólíklegt að þú finnir tilbúnar uppskriftir í hvítbókum og greinum liðsins, og við munum svo sannarlega ekki finna tilbúnar uppskriftir. ákveðið á næsta ári eða tveimur og skrifaðu „gerðu þetta svona, nákvæmlega rétt“.

Bless, fyrir PVRB okkar í blockchain sem verið er að þróa Haya, við sættum okkur við að nota þröskuld BLS undirskriftir, við ætlum að innleiða PVRB á samstöðustigi, þar sem sannprófun í snjöllum samningum með viðunandi öryggisstigi er ekki enn möguleg. Það er mögulegt að við notum tvö kerfi í einu: í fyrsta lagi dýra leyndarmálsdeilingu til að búa til langtíma random_seed, og síðan notum við það sem grunn fyrir hátíðni slembiframleiðslu með því að nota ákveðna þröskuld BLS undirskriftir, kannski munum við takmarka okkur við aðeins eitt af kerfunum. Því miður er ómögulegt að segja fyrirfram hver bókunin verður; það eina góða er að eins og í vísindum, í verkfræðilegum vandamálum, er neikvæð niðurstaða einnig afleiðing og hver ný tilraun til að leysa vandamálið er annað skref fyrir rannsókn allra sem koma að vandanum. Til að mæta viðskiptakröfum leysum við sérstakt hagnýtt vandamál - að útvega leikjaforritum áreiðanlega uppsprettu óreiðu, svo við verðum líka að borga eftirtekt til blockchain sjálfrar, sérstaklega málefni keðju endanleika og netstjórnunar.

Og jafnvel þó að við sjáum ekki enn sannað ónæmt PVRB í blockchains, sem hefði verið notað í nægan tíma til að vera prófað með raunverulegum forritum, mörgum endurskoðunum, álagi og auðvitað raunverulegum árásum, en fjöldi mögulegra leiða staðfestir það lausn er til, og hvað af þessum reikniritum mun að lokum leysa vandamálið. Við munum vera fús til að deila niðurstöðunum og þakka öðrum teymum sem eru einnig að vinna að þessu máli fyrir greinar og kóða sem gera verkfræðingum kleift að stíga ekki tvisvar á sömu hrífuna.

Svo, þegar þú hittir forritara sem hannar dreifð af handahófi, vertu gaum og umhyggjusamur og veittu sálfræðihjálp ef þörf krefur :)

Heimild: www.habr.com