Cyflwyniad

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

Yn yr un modd â'r cysyniad o seiffr hollol gryf o cryptograffeg, mae protocolau gwirioneddol “Handamp Dilysadwy yn Gyhoeddus” (PVRB o hyn ymlaen) ond yn ceisio mynd mor agos â phosibl at y cynllun delfrydol, oherwydd mewn rhwydweithiau go iawn nid yw'n berthnasol yn ei ffurf bur: mae angen cytuno'n llym ar un darn, rhaid cael llawer o rowndiau, a rhaid i bob neges fod yn berffaith gyflym ac yn cael ei chyflwyno bob amser. Wrth gwrs, nid yw hyn yn wir mewn rhwydweithiau go iawn. Felly, wrth ddylunio PVRBs ar gyfer tasgau penodol mewn cadwyni bloc modern, yn ogystal â'r amhosibl o reoli'r hap a'r cryfder cryptograffig sy'n deillio o hynny, mae llawer mwy o broblemau pensaernïol a thechnegol pur yn codi.

Ar gyfer PVRB, mae'r blockchain ei hun yn ei hanfod yn gyfrwng cyfathrebu lle mae negeseuon = trafodion. Mae hyn yn caniatáu ichi dynnu'n rhannol o broblemau rhwydwaith, diffyg danfon negeseuon, problemau gyda nwyddau canol - mae'r rhwydwaith datganoledig yn cymryd yr holl risgiau hyn, a'i brif werth ar gyfer PVRB yw'r anallu i ddirymu neu lygru trafodiad a anfonwyd eisoes - mae hyn yn gwneud hynny. peidio â chaniatáu i gyfranogwyr wrthod cymryd rhan yn y protocol, oni bai eu bod wedi cynnal ymosodiad llwyddiannus ar gonsensws. Mae'r lefel hon o ddiogelwch yn dderbyniol, felly dylai PVRB wrthsefyll cydgynllwynio gan gyfranogwyr i'r un graddau yn union â'r brif gadwyn blockchain. Hefyd, mae hyn yn awgrymu bod yn rhaid i'r PVRB fod yn rhan o'r consensws os yw'r rhwydwaith yn cytuno ar y prif gadwyn bloc, hyd yn oed os yw hefyd yn cytuno ar yr unig hap canlyniadol teg. Neu, yn syml, protocol annibynnol yw PVRB a weithredir gan gontract smart sy'n gweithio'n anghydamserol mewn perthynas â'r blockchain a'r blociau. Mae gan y ddau ddull eu manteision a'u hanfanteision, ac mae'r dewis rhyngddynt yn hynod o ddibwys.

Dwy ffordd o weithredu PVRB

Gadewch inni ddisgrifio'n fanylach ddau opsiwn ar gyfer gweithredu PVRB - y fersiwn annibynnol, sy'n gweithio gan ddefnyddio contract smart sy'n annibynnol ar y blockchain, a'r fersiwn integredig consensws, sydd wedi'i gynnwys yn y protocol, y mae'r rhwydwaith yn cytuno arno ar y blockchain a'r trafodion i'w cynnwys. Ym mhob achos, byddaf yn golygu peiriannau blockchain poblogaidd: Ethereum, EOS, a phawb sy'n debyg iddynt yn y ffordd y maent yn cynnal ac yn prosesu contractau smart.

Contract annibynnol

Yn y fersiwn hon, mae PVRB yn gontract smart sy'n derbyn trafodion cynhyrchwyr ar hap (y cyfeirir ati yma wedi hyn fel RP), yn eu prosesu, yn cyfuno'r canlyniadau, ac, o ganlyniad, yn cyrraedd gwerth penodol y gall unrhyw ddefnyddiwr ei dderbyn o'r contract hwn. Mae'n bosibl na fydd y gwerth hwn yn cael ei storio'n uniongyrchol yn y contract, ond yn hytrach yn cael ei gynrychioli gan ddata yn unig y gellir cael un gwerth ac un yn unig o'r hap sy'n deillio ohono yn bendant. Yn y cynllun hwn, mae RPs yn ddefnyddwyr y blockchain, a gellir caniatáu i unrhyw un gymryd rhan yn y broses gynhyrchu.

Mae'r opsiwn gyda chontract annibynnol yn dda:

• hygludedd (gellir llusgo contractau o blockchain i blockchain)
• rhwyddineb gweithredu a phrofi (mae contractau'n hawdd eu hysgrifennu a'u profi)
• cyfleustra wrth weithredu cynlluniau economaidd (mae'n hawdd gwneud eich tocyn eich hun, y mae ei resymeg yn gwasanaethu dibenion PVRB)
• posibilrwydd o lansio ar blockchains sydd eisoes yn gweithio

Mae ganddo hefyd anfanteision:

• cyfyngiadau cryf ar adnoddau cyfrifiadurol, maint trafodion a storio (mewn geiriau eraill, cpu/mem/io)
• cyfyngiadau ar weithrediadau o fewn y contract (nid yw pob cyfarwyddyd ar gael, mae'n anodd cysylltu llyfrgelloedd allanol)
• anallu i drefnu negeseuon yn gyflymach nag y mae trafodion wedi'u cynnwys yn y blockchain

Mae'r opsiwn hwn yn addas ar gyfer gweithredu PVRB y mae angen ei redeg ar rwydwaith sy'n bodoli eisoes, nad yw'n cynnwys cryptograffeg gymhleth ac nid oes angen nifer fawr o ryngweithiadau.

Consensws-integredig

Yn y fersiwn hon, mae PVRB yn cael ei weithredu yn y cod nod blockchain, wedi'i ymgorffori neu'n rhedeg ochr yn ochr â chyfnewid negeseuon rhwng nodau blockchain. Ysgrifennir canlyniadau'r protocol yn uniongyrchol i'r blociau a gynhyrchir, ac anfonir negeseuon protocol dros y rhwydwaith p2p rhwng nodau. Gan fod y protocol yn arwain at rifau sydd i'w hysgrifennu mewn blociau, rhaid i'r rhwydwaith gyrraedd consensws arnynt. Mae hyn yn golygu bod yn rhaid i negeseuon PVRB, fel trafodion, gael eu dilysu gan nodau a'u cynnwys mewn blociau fel y gall unrhyw gyfranogwr rhwydwaith ddilysu cydymffurfiaeth â'r protocol PVRB. Mae hyn yn ein harwain yn awtomatig at yr ateb amlwg - os yw'r rhwydwaith yn cytuno ar gonsensws ynghylch bloc a thrafodion ynddo, yna dylai PVRB fod yn rhan o'r consensws, ac nid yn brotocol ar ei ben ei hun. Fel arall, mae'n bosibl bod bloc yn ddilys o safbwynt consensws, ond ni ddilynir y protocol PVRB, ac o safbwynt PVRB ni ellir derbyn y bloc. Felly os dewisir yr opsiwn “integredig consensws”, daw'r PVRB yn rhan bwysig o'r consensws.

Wrth ddisgrifio gweithrediadau PVRB ar lefel consensws rhwydwaith, ni all rhywun o gwbl osgoi materion terfynoldeb. Mae terfynoldeb yn fecanwaith a ddefnyddir mewn consensws penderfynol sy'n ymrwymo bloc (a'r gadwyn sy'n arwain ato) sy'n derfynol ac na fydd byth yn cael ei daflu, hyd yn oed os bydd fforch gyfochrog yn digwydd. Er enghraifft, yn Bitcoin nid oes mecanwaith o'r fath - os byddwch yn cyhoeddi cadwyn o fwy o gymhlethdod, bydd yn disodli unrhyw un llai cymhleth, waeth beth fo hyd y cadwyni. Ac yn EOS, er enghraifft, y rhai olaf yw'r hyn a elwir yn Blociau Diwrthdroadwy Olaf, sy'n ymddangos ar gyfartaledd bob 432 bloc (12 * 21 + 12 * 15, cyn-bleidlais + rhag-ymrwymo). Mae'r broses hon yn ei hanfod yn aros am 2/3 o lofnodion bloc-gynhyrchwyr (y cyfeirir atynt o hyn ymlaen fel BP). Pan fydd ffyrc yn ymddangos sy'n hŷn na'r LIB diwethaf, cânt eu taflu. Mae'r mecanwaith hwn yn ei gwneud hi'n bosibl gwarantu bod y trafodiad wedi'i gynnwys yn y blockchain ac ni fydd byth yn cael ei rolio'n ôl, ni waeth pa adnoddau sydd gan yr ymosodwr. Hefyd, mae'r blociau terfynol yn flociau wedi'u llofnodi gan 2/3 BP yn Hyperledger, Tendermint a chonsensws eraill sy'n seiliedig ar pBFT. Hefyd, mae'n gwneud synnwyr i wneud protocol ar gyfer sicrhau terfynoldeb ychwanegiad i gonsensws, gan y gall weithio'n anghydamserol gyda chynhyrchu a chyhoeddi blociau. Dyma un dda erthygl am derfynoldeb yn Ethereum.

Mae terfynoldeb yn hynod bwysig i ddefnyddwyr, a allai hebddo gael eu hunain yn ddioddefwyr ymosodiad “gwariant dwbl”, lle mae BP yn “dal” blociau, ac yn eu cyhoeddi ar ôl i’r rhwydwaith “weld” trafodiad da. Os nad oes unrhyw derfynoldeb, yna mae'r fforc cyhoeddedig yn disodli'r bloc gyda thrafodiad “da” gydag un arall, o fforc “drwg”, lle mae'r un arian yn cael ei drosglwyddo i gyfeiriad yr ymosodwr. Yn achos PVRB, mae'r gofynion ar gyfer terfynoldeb hyd yn oed yn fwy llym, gan fod adeiladu ffyrch ar gyfer PVRB yn golygu'r cyfle i ymosodwr baratoi sawl opsiwn ar hap er mwyn cyhoeddi'r un mwyaf proffidiol, ac mae cyfyngu ar amser ymosodiad posibl yn un. ateb da.

Felly, yr opsiwn gorau yw cyfuno PVRB a therfynoldeb yn un protocol - yna'r bloc terfynol = hap terfynol, a dyma'n union yr hyn yr oedd angen i ni ei gael. Nawr bydd chwaraewyr yn derbyn hap gwarantedig mewn N eiliad, a gallant fod yn sicr ei bod yn amhosibl ei rolio'n ôl neu ei ailchwarae eto.

Mae'r opsiwn integredig consensws yn dda:

• y posibilrwydd o weithredu asyncronig mewn perthynas â chynhyrchu blociau - cynhyrchir blociau fel arfer, ond ochr yn ochr â hyn, gall y protocol PVRB weithio, nad yw'n cynhyrchu hap ar gyfer pob bloc
• y gallu i weithredu hyd yn oed cryptograffeg trwm, heb y cyfyngiadau a osodir ar gontractau smart
• y gallu i drefnu cyfnewid negeseuon yn gyflymach nag y mae trafodion wedi'u cynnwys yn y blockchain, er enghraifft, gall rhan o'r protocol weithio rhwng nodau heb ddosbarthu negeseuon dros y rhwydwaith

Mae ganddo hefyd anfanteision:

• Anawsterau wrth brofi a datblygu - bydd yn rhaid i chi efelychu gwallau rhwydwaith, nodau coll, ffyrc caled rhwydwaith
• Mae angen fforch galed rhwydwaith ar gyfer gwallau gweithredu

Mae gan y ddau ddull o weithredu PVRB hawl i fywyd, ond mae gweithredu contractau smart mewn blockchains modern yn dal i fod yn eithaf cyfyngedig mewn adnoddau cyfrifiadurol, ac mae unrhyw drawsnewid i cryptograffeg difrifol yn aml yn amhosibl. A bydd angen cryptograffeg difrifol arnom, fel y dangosir isod. Er bod y broblem hon yn amlwg dros dro, mae angen cryptograffeg difrifol mewn contractau i ddatrys llawer o broblemau, ac mae'n ymddangos yn raddol (er enghraifft, contractau system ar gyfer zkSNARKs yn Ethereum).

Nid yw Blockchain, sy'n darparu sianel negeseuon protocol tryloyw a dibynadwy, yn gwneud hynny am ddim. Rhaid i unrhyw brotocol datganoledig ystyried y posibilrwydd o ymosodiad Sybil; gall unrhyw gamau gweithredu gael eu gwneud gan luoedd cydunol o gyfrifon lluosog, felly, wrth ddylunio, mae angen ystyried gallu ymosodwyr i greu nifer mympwyol o brotocol. cyfranogwyr yn gweithredu mewn cydgynllwynio.

PVRB a newidynnau bloc.

Wnes i ddim dweud celwydd pan ddywedais nad oes neb eto wedi gweithredu PVRB da, wedi'i brofi gan lawer o gymwysiadau hapchwarae, mewn cadwyni bloc. O ble felly mae cymaint o gymwysiadau gamblo yn dod ar Ethereum ac EOS? Mae hyn yn fy synnu cymaint ag y mae'n eich synnu, o ble cawsant gymaint o hapiau “parhaus” mewn amgylchedd cwbl benderfynol?

Y ffordd orau o gael hap yn y blockchain yw cymryd rhyw fath o wybodaeth “anrhagweladwy” o'r bloc a gwneud un ar hap yn seiliedig arno - yn syml trwy stwnsio un neu fwy o werthoedd. Erthygl dda am broblemau cynlluniau o'r fath yma. Gallwch chi gymryd unrhyw un o'r gwerthoedd "anrhagweladwy" yn y bloc, er enghraifft, yr hash bloc, nifer y trafodion, cymhlethdod rhwydwaith, a gwerthoedd eraill anhysbys ymlaen llaw. Yna hash nhw, un neu fwy, ac, mewn theori, dylech gael hap go iawn. Gallwch hyd yn oed ychwanegu at y papur wihite bod eich cynllun yn “ddiogel ar ôl cwantwm” (gan fod yna swyddogaethau stwnsh gwrth-gwantwm :)).

Ond nid yw hyd yn oed hashes diogel ôl-cwantwm yn ddigon, gwaetha'r modd. Mae'r gyfrinach yn gorwedd yn y gofynion ar gyfer PVRB, gadewch imi eich atgoffa ohonynt o'r erthygl flaenorol:

1. Mae'n rhaid i'r canlyniad fod â dosbarthiad unffurf, h.y. yn seiliedig ar cryptograffeg cryf.
2. Nid yw'n bosibl rheoli unrhyw ddarnau o'r canlyniad. O ganlyniad, ni ellir rhagweld y canlyniad ymlaen llaw.
3. Ni allwch ddifrodi'r protocol cynhyrchu trwy beidio â chymryd rhan yn y protocol neu drwy orlwytho'r rhwydwaith â negeseuon ymosodiad
4. Rhaid i bob un o'r uchod wrthsefyll cydgynllwynio o nifer a ganiateir o gyfranogwyr protocol anonest (er enghraifft, 1/3 o'r cyfranogwyr).

Yn yr achos hwn, dim ond gofyniad 1 sy'n cael ei fodloni, ac ni fodlonir gofyniad 2. Trwy stwnsio gwerthoedd anrhagweladwy o'r bloc, byddwn yn cael dosbarthiad unffurf a hapiau da. Ond o leiaf mae gan BP yr opsiwn i “gyhoeddi’r bloc ai peidio.” Felly, gall BP o leiaf ddewis o DDAU opsiwn ar hap: “ei hun” a'r un a fydd yn troi allan os bydd rhywun arall yn gwneud y bloc. Gall BP “snoop” ymlaen llaw beth fydd yn digwydd os bydd yn cyhoeddi bloc, ac yn syml yn penderfynu ei wneud ai peidio. Felly, wrth chwarae, er enghraifft, “rhyfedd od” neu “goch/du” mewn roulette, dim ond os bydd yn gweld buddugoliaeth y gall gyhoeddi bloc. Mae hyn hefyd yn gwneud y strategaeth o ddefnyddio, er enghraifft, hash bloc “o’r dyfodol” yn anymarferol. Yn yr achos hwn, maen nhw'n dweud y bydd “hap yn cael ei ddefnyddio, a geir trwy stwnsio'r data cyfredol a stwnsh bloc yn y dyfodol gydag uchder o, er enghraifft, N + 42, lle N yw uchder presennol y bloc. Mae hyn yn cryfhau'r cynllun ychydig, ond yn dal i ganiatáu i BP, er yn y dyfodol, ddewis a ddylid dal y bloc neu gyhoeddi.

Mae meddalwedd BP yn yr achos hwn yn dod yn fwy cymhleth, ond dim llawer. Yn syml, wrth ddilysu a chynnwys trafodiad mewn bloc, mae gwiriad cyflym i weld a fydd yna fuddugoliaeth, ac, o bosibl, detholiad o baramedrau un trafodiad i gael tebygolrwydd uchel o ennill. Ar yr un pryd, mae bron yn amhosibl dal BP craff ar gyfer triniaethau o'r fath; bob tro gallwch ddefnyddio cyfeiriadau newydd ac ennill fesul tipyn heb godi amheuaeth.

Felly nid yw dulliau sy'n defnyddio gwybodaeth o'r bloc yn addas fel gweithrediad cyffredinol o PVRB. Mewn fersiwn gyfyngedig, gyda chyfyngiadau ar faint bet, cyfyngiadau ar nifer y chwaraewyr a / neu gofrestriad KYC (i atal un chwaraewr rhag defnyddio cyfeiriadau lluosog), gall y cynlluniau hyn weithio ar gyfer gemau bach, ond dim byd mwy.

PVRB ac ymrwymo-datgelu.

Iawn, diolch i hashing ac o leiaf natur anrhagweladwy cymharol yr hash bloc a newidynnau eraill. Os ydych chi'n datrys problem glowyr blaen, dylech gael rhywbeth mwy addas. Gadewch i ni ychwanegu defnyddwyr at y cynllun hwn - gadewch iddynt hefyd ddylanwadu ar yr hap: bydd unrhyw weithiwr cymorth technegol yn dweud wrthych mai'r peth mwyaf hap mewn systemau TG yw gweithredoedd defnyddwyr :)

Nid yw cynllun naïf, pan fydd defnyddwyr yn anfon rhifau ar hap yn syml a'r canlyniad yn cael ei gyfrifo fel, er enghraifft, stwnsh o'u swm, yn addas. Yn yr achos hwn, gall y chwaraewr olaf, trwy ddewis ei hap ei hun, reoli beth fydd y canlyniad. Dyna pam y defnyddir y patrwm ymrwymo-datgelu a ddefnyddir yn eang iawn. Yn gyntaf, mae cyfranogwyr yn anfon hashes o'u hapiau (ymrwymiadau), ac yna'n agor yr hapiau eu hunain (datgeliadau). Dim ond ar ôl i'r ymrwymiadau angenrheidiol gael eu casglu y mae'r cam “datgelu” yn dechrau, felly gall cyfranogwyr anfon yr union stwnsh ar hap y gwnaethant anfon yn gynharach ohono. Nawr gadewch i ni roi hyn i gyd ynghyd â pharamedrau bloc, ac yn well nag un a gymerwyd o'r dyfodol (dim ond yn un o'r blociau yn y dyfodol y gellir dod o hyd i hap), a voila - mae'r hap yn barod! Nawr mae unrhyw chwaraewr yn dylanwadu ar yr hap sy'n deillio o hynny, a gall “drechu” y BP maleisus trwy ei ddiystyru â'i hap ei hun, anhysbys ymlaen llaw... Gallwch hefyd ychwanegu amddiffyniad rhag difrodi'r protocol trwy beidio â'i agor yn y cam datgelu - yn syml drwy ei gwneud yn ofynnol i swm penodol gael ei atodi i’r trafodiad wrth ymrwymo — blaendal sicrwydd, a fydd yn cael ei ddychwelyd yn ystod y weithdrefn ddatgelu yn unig. Yn yr achos hwn, bydd ymrwymo a pheidio â datgelu yn amhroffidiol.

Roedd yn ymgais dda, ac mae cynlluniau o'r fath hefyd yn bodoli mewn DApps hapchwarae, ond gwaetha'r modd, nid yw hyn yn ddigon eto. Nawr nid yn unig y glöwr, ond hefyd gall unrhyw gyfranogwr yn y protocol ddylanwadu ar y canlyniad. Mae'n dal yn bosibl rheoli'r gwerth ei hun, gyda llai o amrywioldeb ac ar gost, ond, fel yn achos y glöwr, os yw canlyniadau'r lluniad yn fwy gwerthfawr na'r ffi ar gyfer cymryd rhan yn y protocol PVRB, yna yr hap Gall -cynhyrchydd(RP) benderfynu a ddylid datgelu a gall barhau i ddewis o ddau opsiwn ar hap o leiaf.
Ond daeth yn bosibl cosbi'r rhai sy'n cyflawni ac nad ydynt yn datgelu, a bydd y cynllun hwn yn ddefnyddiol. Mae ei symlrwydd yn fantais ddifrifol - mae protocolau mwy difrifol yn gofyn am gyfrifiadau llawer mwy pwerus.

PVRB a llofnodion penderfynol.

Mae ffordd arall o orfodi’r RP i ddarparu rhif ffug-hap na all ddylanwadu arno os caiff “rhaglun” ei ddarparu – llofnod penderfynol yw hwn. Mae llofnod o'r fath, er enghraifft, yn RSA, ac nid yw'n ECS. Os oes gan RP bâr o allweddi: RSA ac ECC, a'i fod yn llofnodi gwerth penodol gyda'i allwedd breifat, yna yn achos RSA bydd yn cael UN A DIM OND UN llofnod, ac yn achos ECS gall gynhyrchu unrhyw nifer o llofnodion dilys gwahanol. Mae hyn oherwydd wrth greu llofnod ECS, defnyddir rhif ar hap, a ddewisir gan yr arwyddwr, a gellir ei ddewis mewn unrhyw ffordd, gan roi cyfle i'r llofnodwr ddewis un o sawl llofnod. Yn achos RSA: “un mewnbwn gwerth” + “un pâr allweddol” = “un llofnod”. Mae'n amhosibl rhagweld pa lofnod y bydd RP arall yn ei gael, felly gellir trefnu PVRB gyda llofnodion penderfynol trwy gyfuno llofnodion RSA sawl cyfranogwr a lofnododd yr un gwerth. Er enghraifft, yr hap blaenorol. Mae'r cynllun hwn yn arbed llawer o adnoddau, oherwydd mae llofnodion yn gadarnhad o'r ymddygiad cywir yn unol â'r protocol ac yn ffynhonnell hap.

Fodd bynnag, hyd yn oed gyda llofnodion penderfynol, mae'r cynllun yn dal i fod yn agored i broblem yr “actor olaf”. Gall y cyfranogwr olaf benderfynu o hyd a yw am gyhoeddi'r llofnod ai peidio, a thrwy hynny reoli'r canlyniad. Gallwch chi addasu'r cynllun, ychwanegu hashes bloc ato, gwneud rowndiau fel na ellir rhagweld y canlyniad ymlaen llaw, ond mae'r holl dechnegau hyn, hyd yn oed gan gymryd i ystyriaeth llawer o addasiadau, yn dal i adael problem dylanwad un cyfranogwr ar y grŵp heb ei ddatrys. arwain at amgylchedd di-ymddiried a dim ond o dan gyfyngiadau economaidd ac amser y gall weithio. Yn ogystal, mae maint yr allweddi RSA (1024 a 2048 bits) yn eithaf mawr, ac mae'r maint ar gyfer trafodion blockchain yn baramedr hynod bwysig. Mae'n debyg nad oes ffordd syml o ddatrys y broblem, gadewch i ni symud ymlaen.

PVRB a chynlluniau rhannu cyfrinachol

Mewn cryptograffeg, mae yna gynlluniau a all ganiatáu i'r rhwydwaith gytuno ar un ac un gwerth PVRB yn unig, tra bod cynlluniau o'r fath yn gwrthsefyll unrhyw weithredoedd maleisus gan rai cyfranogwyr. Un protocol defnyddiol sy'n werth ymgyfarwyddo ag ef yw cynllun rhannu cyfrinachol Shamir. Mae'n gwasanaethu i rannu cyfrinach (er enghraifft, allwedd gyfrinachol) yn sawl rhan, a dosbarthu'r rhannau hyn i gyfranogwyr N. Mae'r gyfrinach yn cael ei dosbarthu yn y fath fodd fel bod rhannau M allan o N yn ddigon i'w hadennill, a gall y rhain fod yn unrhyw rannau M. Os ar fysedd, yna cael graff o swyddogaeth anhysbys, mae'r cyfranogwyr yn cyfnewid pwyntiau ar y graff, ac ar ôl derbyn pwyntiau M, gellir adfer y swyddogaeth gyfan.
Rhoddir esboniad da yn wiki ond mae chwarae ag ef yn ymarferol er mwyn chwarae'r protocol yn eich pen yn ddefnyddiol ar gyfer demo tudalen.

Pe bai cynllun FSSS (Rhannu Cyfrinachol Fiat-Shamir) yn berthnasol yn ei ffurf bur, byddai'n PVRB annistrywiol. Yn ei ffurf symlaf, efallai y bydd y protocol yn edrych fel hyn:

• Mae pob cyfranogwr yn cynhyrchu ei hap ei hun ac yn dosbarthu cyfrannau ohono i gyfranogwyr eraill
• Mae pob cyfranogwr yn datgelu ei ran ef o gyfrinachau'r cyfranogwyr eraill
• Os oes gan gyfranogwr fwy nag M, yna gellir cyfrifo nifer y cyfranogwr hwn, a bydd yn unigryw, waeth beth fo'r set o gyfranogwyr a ddatgelwyd.
• Y cyfuniad o hapiau a ddatgelwyd yw'r PVRB a ddymunir

Yma, nid yw cyfranogwr unigol bellach yn dylanwadu ar ganlyniadau'r protocol, ac eithrio mewn achosion lle mae cyflawni'r trothwy datgelu hap yn dibynnu arno yn unig. Felly, mae'r protocol hwn, os oes cyfran ofynnol o RPs yn gweithio ar y protocol ac ar gael, yn gweithio, yn gweithredu'r gofynion ar gyfer cryfder cryptograffig, ac yn gwrthsefyll y broblem "actor olaf".

Gallai hyn fod yn opsiwn delfrydol, mae'r cynllun PVRB hwn sy'n seiliedig ar rannu cyfrinachol Fiat-Shamir yn cael ei ddisgrifio er enghraifft yn hwn erthygl. Ond, fel y soniwyd uchod, os ceisiwch ei gymhwyso'n uniongyrchol yn y blockchain, mae cyfyngiadau technegol yn ymddangos. Dyma enghraifft o weithrediad prawf o'r protocol yn y contract smart EOS a'i ran bwysicaf - gwirio'r cyfranogwr cyfran cyhoeddedig: код. Gallwch weld o'r cod bod dilysu prawf yn gofyn am nifer o luosiadau sgalar, ac mae'r niferoedd a ddefnyddir yn fawr iawn. Dylid deall bod gwirio mewn cadwyni bloc yn digwydd ar hyn o bryd pan fydd y cynhyrchydd bloc yn prosesu'r trafodiad, ac yn gyffredinol, rhaid i unrhyw gyfranogwr wirio cywirdeb y protocol yn hawdd, felly mae'r gofynion ar gyfer cyflymder y swyddogaeth wirio yn ddifrifol iawn. . Yn yr opsiwn hwn, roedd yr opsiwn yn aneffeithiol, gan nad oedd y dilysiad yn cyd-fynd â therfyn y trafodion (0.5 eiliad).

Effeithlonrwydd dilysu yw un o'r gofynion pwysicaf ar gyfer defnyddio, yn gyffredinol, unrhyw gynlluniau cryptograffig datblygedig yn y blockchain. Creu proflenni, paratoi negeseuon - gellir cymryd y gweithdrefnau hyn oddi ar y gadwyn a'u perfformio ar gyfrifiaduron perfformiad uchel, ond ni ellir osgoi dilysu - mae hwn yn ofyniad pwysig arall ar gyfer PVRB.

PVRB a llofnodion trothwy

Ar ôl dod yn gyfarwydd â'r cynllun rhannu cyfrinachol, fe wnaethom ddarganfod dosbarth cyfan o brotocolau wedi'u huno gan yr allweddair “trothwy”. Pan fo datgelu rhywfaint o wybodaeth yn gofyn am gyfranogiad M cyfranogwyr gonest allan o N, a gall y set o gyfranogwyr gonest fod yn is-set mympwyol o N, rydym yn siarad am gynlluniau “trothwy”. Nhw sy'n caniatáu inni ddelio â'r broblem “actor olaf”, nawr os na fydd yr ymosodwr yn datgelu ei ran o'r gyfrinach, bydd cyfranogwr gonest arall yn ei wneud drosto. Mae'r cynlluniau hyn yn caniatáu cytundeb ar un ac un ystyr yn unig, hyd yn oed os yw'r protocol yn cael ei ddifrodi gan rai o'r cyfranogwyr.

Roedd y cyfuniad o lofnodion penderfyniaethol a chynlluniau trothwy yn ei gwneud yn bosibl datblygu cynllun cyfleus ac addawol iawn ar gyfer gweithredu PVRB - llofnod trothwy penderfyniaethol yw'r rhain. Yma erthygl am y gwahanol ddefnyddiau o lofnodion trothwy, a dyma un da arall darllen hir oddi wrth Dash.

Mae'r erthygl olaf yn disgrifio llofnodion BLS (mae BLS yn sefyll am Boneh-Lynn-Shacham, yma erthygl), sydd ag ansawdd pwysig iawn a hynod gyfleus i raglenwyr - gellir cyfuno allweddi cyhoeddus, cyfrinachol, allweddi cyhoeddus a llofnodion BLS â'i gilydd gan ddefnyddio gweithrediadau mathemategol syml, tra bod eu cyfuniadau yn parhau i fod yn allweddi a llofnodion dilys, sy'n eich galluogi i agregu llawer yn hawdd llofnodion i mewn i un a llawer o allweddi cyhoeddus i mewn i un. Maent hefyd yn benderfyniaethol ac yn cynhyrchu'r un canlyniad ar gyfer yr un data mewnbwn. Diolch i'r ansawdd hwn, mae cyfuniadau o lofnodion BLS eu hunain yn allweddi dilys, sy'n caniatáu ar gyfer gweithredu opsiwn lle mae cyfranogwyr M o N yn cynhyrchu un ac un llofnod yn unig sy'n benderfynadwy, yn wiriadwy yn gyhoeddus, ac yn anrhagweladwy nes iddo gael ei agor gan y Mth cyfranogwr .

Mewn cynllun gyda llofnodion BLS trothwy, mae pob cyfranogwr yn llofnodi rhywbeth gan ddefnyddio BLS (er enghraifft, yr hap blaenorol), a'r llofnod trothwy cyffredin yw'r hap a ddymunir. Mae priodweddau cryptograffig llofnodion BLS yn bodloni'r gofynion ar gyfer ansawdd ar hap, mae'r rhan drothwy yn amddiffyn rhag “actor olaf”, ac mae cyfuniad unigryw allweddi yn ei gwneud hi'n bosibl gweithredu llawer o algorithmau mwy diddorol sy'n caniatáu, er enghraifft, agregu negeseuon protocol yn effeithlon. .

Felly, os ydych chi'n adeiladu PVRB ar eich blockchain, mae'n debyg y bydd gennych chi gynllun llofnodion trothwy BLS yn y pen draw, mae sawl prosiect eisoes yn ei ddefnyddio. Er enghraifft, mae Dfinity (yma meincnod sy'n gweithredu'r gylched, a yma enghraifft o weithredu rhannu cyfrinach dilysadwy), neu Keep.network (dyma eu beacon ar hap papur melynac yma enghraifft contract smart sy'n gwasanaethu'r protocol).

Gweithredu PVRB

Yn anffodus, nid ydym yn dal i weld protocol parod ar waith mewn cadwyni bloc PVRB sydd wedi profi ei ddiogelwch a'i sefydlogrwydd. Er bod y protocolau eu hunain yn barod, nid yw'n hawdd eu cymhwyso'n dechnegol i atebion presennol. Ar gyfer systemau canolog, nid yw PVRB yn gwneud synnwyr, ac mae rhai datganoledig wedi'u cyfyngu'n llym ym mhob adnodd cyfrifiadurol: CPU, cof, storio, I/O. Mae dylunio PVRB yn gyfuniad o wahanol brotocolau er mwyn creu rhywbeth sy'n bodloni'r holl ofynion ar gyfer rhai blockchain hyfyw o leiaf. Mae un protocol yn cyfrifo'n fwy effeithlon, ond mae angen mwy o negeseuon rhwng RPs, tra bod angen ychydig iawn o negeseuon ar y llall, ond gall creu prawf fod yn dasg sy'n cymryd degau o funudau, neu hyd yn oed oriau.

Byddaf yn rhestru'r ffactorau y bydd yn rhaid i chi eu hystyried wrth ddewis PVRB o safon:

• Cryfder cryptograffig. Rhaid i'ch PVRB fod yn gwbl ddiduedd, heb unrhyw allu i reoli un darn. Mewn rhai cynlluniau nid yw hyn yn wir, felly ffoniwch cryptograffydd
• Problem yr “actor olaf”.. Rhaid i'ch PVRB allu gwrthsefyll ymosodiadau lle gall ymosodwr sy'n rheoli un neu fwy o RPs ddewis un o ddau ganlyniad.
• Problem sabotage protocol. Mae'n rhaid i'ch PVRB allu gwrthsefyll ymosodiadau lle mae ymosodwr sy'n rheoli un neu fwy o RP yn penderfynu a yw am fod ar hap ai peidio a gellir ei warantu neu gyda thebygolrwydd penodol i ddylanwadu ar hyn.
• Problem nifer y negeseuon. Dylai eich RPs anfon lleiafswm o negeseuon i'r blockchain ac osgoi gweithredoedd cydamserol cymaint â phosibl fel sefyllfaoedd fel “Anfonais rywfaint o wybodaeth, rwy'n aros am ymateb gan gyfranogwr penodol.” Mewn rhwydweithiau p2p, yn enwedig rhai gwasgaredig yn ddaearyddol, ni ddylech ddibynnu ar ymateb cyflym
• Problem cymhlethdod cyfrifiannol. Dylai fod yn hawdd iawn dilysu unrhyw gam o'r gadwyn PVRB ar y gadwyn, gan ei fod yn cael ei berfformio gan holl gleientiaid llawn y rhwydwaith. Os gwneir y gweithrediad gan ddefnyddio contract smart, yna mae'r gofynion cyflymder yn llym iawn
• Problem hygyrchedd a bywiogrwydd. Dylai eich PVRB ymdrechu i fod yn wydn i sefyllfaoedd lle na fydd rhan o'r rhwydwaith ar gael am gyfnod o amser a rhan o'r RP yn rhoi'r gorau i weithio.
• Y broblem o sefydlu dibynadwy a dosbarthiad allweddol cychwynnol. Os yw'ch PVRB yn defnyddio gosodiad sylfaenol y protocol, yna mae hon yn stori fawr a difrifol ar wahân. Yma enghraifft. Os oes rhaid i gyfranogwyr ddweud eu hallweddi wrth ei gilydd cyn dechrau'r protocol, mae hyn hefyd yn broblem os bydd cyfansoddiad y cyfranogwyr yn newid
• Problemau datblygu. Argaeledd llyfrgelloedd yn yr ieithoedd gofynnol, eu diogelwch a’u perfformiad, cyhoeddusrwydd, profion cymhleth, ac ati.

Er enghraifft, mae gan lofnodion trothwy BLS broblem sylweddol - cyn dechrau gweithio, mae'n rhaid i gyfranogwyr ddosbarthu allweddi i'w gilydd, gan drefnu grŵp y bydd y trothwy yn gweithio o'i fewn. Mae hyn yn golygu y bydd yn rhaid i o leiaf un rownd o gyfnewid mewn rhwydwaith datganoledig aros, ac o ystyried bod y rand a gynhyrchir, er enghraifft, yn angenrheidiol mewn gemau, bron mewn amser real, mae hyn yn golygu bod difrodi'r protocol yn bosibl ar hyn o bryd. , a manteision y cynllun trothwy yn cael eu colli. Mae'r broblem hon eisoes yn symlach na'r rhai blaenorol, ond mae'n dal i fod angen datblygu gweithdrefn ar wahân ar gyfer ffurfio grwpiau trothwy, y bydd yn rhaid eu diogelu'n economaidd, trwy adneuon a thynnu arian yn ôl (slashing) gan gyfranogwyr nad ydynt yn dilyn y protocol. Hefyd, nid yw dilysu BLS gyda lefel dderbyniol o ddiogelwch yn ffitio, er enghraifft, i drafodiad safonol EOS neu Ethereum - yn syml, nid oes digon o amser ar gyfer dilysu. Cod y contract yw WebAssembly neu EVM, a weithredir gan beiriant rhithwir. Nid yw swyddogaethau cryptograffig yn cael eu gweithredu'n frodorol (eto), ac maent yn gweithio ddegau o weithiau'n arafach na llyfrgelloedd cryptograffig confensiynol. Nid yw llawer o brotocolau yn bodloni'r gofynion yn syml yn seiliedig ar gyfaint allweddol, er enghraifft darnau 1024 a 2048 ar gyfer RSA, 4-8 gwaith yn fwy na'r llofnod trafodiad safonol yn Bitcoin ac Ethereum.

Mae presenoldeb gweithrediadau mewn gwahanol ieithoedd rhaglennu hefyd yn chwarae rhan - ac nid oes llawer ohonynt, yn enwedig ar gyfer protocolau newydd. Mae'r opsiwn gydag integreiddio i gonsensws yn gofyn am ysgrifennu protocol yn iaith y platfform, felly bydd yn rhaid i chi chwilio am god yn Go for geth, yn Rust for Parity, yn C ++ ar gyfer EOS. Bydd yn rhaid i bawb chwilio am god JavaScript, a chan nad yw JavaScript a cryptograffeg yn ffrindiau arbennig o agos, bydd WebAssembly yn helpu, sydd bellach yn bendant yn honni mai hwn yw'r safon Rhyngrwyd bwysig nesaf.

Casgliad

Rwy'n gobeithio yn yr un blaenorol Erthygl Llwyddais i'ch argyhoeddi bod cynhyrchu rhifau ar hap ar y blockchain yn hanfodol ar gyfer llawer o agweddau ar fywyd rhwydweithiau datganoledig, a gyda'r erthygl hon dangosais fod y dasg hon yn hynod uchelgeisiol ac anodd, ond mae atebion da eisoes yn bodoli. Yn gyffredinol, mae dyluniad terfynol y protocol yn bosibl dim ond ar ôl cynnal profion enfawr sy'n ystyried pob agwedd o setup i efelychu bai, felly mae'n annhebygol y byddwch yn dod o hyd i ryseitiau parod mewn papurau gwyn ac erthyglau tîm, ac yn sicr ni fyddwn yn gwneud hynny. penderfynwch yn y flwyddyn neu ddwy nesaf ysgrifennwch “gwnewch o fel hyn, yn union iawn.”

Hwyl, ar gyfer ein PVRB yn y blockchain sy'n cael ei ddatblygu Haya, fe wnaethom setlo ar ddefnyddio llofnodion BLS trothwy, rydym yn bwriadu gweithredu PVRB ar y lefel consensws, gan nad yw dilysu mewn contractau smart gyda lefel dderbyniol o ddiogelwch yn bosibl eto. Mae'n bosibl ein bod yn defnyddio dau gynllun ar unwaith: yn gyntaf, rhannu cyfrinachol drud i greu hap_seed hirdymor, ac yna rydym yn ei ddefnyddio fel sail ar gyfer cynhyrchu hap amledd uchel gan ddefnyddio llofnodion BLS trothwy penderfynol, efallai y byddwn yn cyfyngu ein hunain i ddim ond un o'r cynlluniau. Yn anffodus, mae'n amhosibl dweud ymlaen llaw beth fydd y protocol; yr unig beth da yw, fel mewn gwyddoniaeth, mewn problemau peirianneg, mae canlyniad negyddol hefyd yn ganlyniad, ac mae pob ymgais newydd i ddatrys y broblem yn gam arall i ymchwil pawb sy'n ymwneud â'r broblem. Er mwyn bodloni gofynion busnes, rydym yn datrys problem ymarferol benodol - darparu cymwysiadau hapchwarae gyda ffynhonnell ddibynadwy o entropi, felly mae'n rhaid i ni hefyd roi sylw i'r blockchain ei hun, yn enwedig materion terfynoldeb cadwyn a llywodraethu rhwydwaith.

Ac er nad ydym eto'n gweld PVRB gwrthsefyll profedig mewn cadwyni bloc, a fyddai wedi cael ei ddefnyddio am ddigon o amser i gael ei brofi gan gymwysiadau go iawn, archwiliadau lluosog, llwythi, ac wrth gwrs, ymosodiadau go iawn, ond mae nifer y llwybrau posibl yn cadarnhau hynny mae datrysiad yn bodoli, a beth - o'r algorithmau hyn fydd yn datrys y broblem yn y pen draw. Byddwn yn hapus i rannu'r canlyniadau a diolch i dimau eraill sydd hefyd yn gweithio ar y mater hwn am erthyglau a chod sy'n caniatáu i beirianwyr beidio â chamu ar yr un rhaca ddwywaith.

Felly, pan fyddwch chi'n cwrdd â rhaglennydd sy'n dylunio hap datganoledig, byddwch yn sylwgar ac yn ofalgar, a darparwch gymorth seicolegol os oes angen :)

Ffynhonnell: hab.com