Hyrje
function getAbsolutishtRastësishëmNumer() {
return 4; // kthen numrin absolutisht rastësor!
}Ashtu si në rastin e konceptit të ciphrit absolutisht të sigurt nga kriptografia, protokollet reale "Publicly Verifiable Random Beacon" (PVRB) përpiqen vetëm të afrohen sa më shumë me skemën ideale, pasi në rrjetet reale ajo nuk është e zbatueshme në formën e saj të pastër: duhet të bien dakord vetëm për një bit, duhet të ketë shumë raunde, dhe të gjitha mesazhet duhet të jenë të shpejta dhe të dorëzohen gjithmonë. Natyrisht, në rrjetet reale kjo nuk ndodh. Prandaj, gjatë projektimit të PVRB për detyra specifike në blockchain moderne, përveç pamundësisë për të kontrolluar rastësinë e marrë dhe qëndrueshmërinë kriptografike, paraqiten edhe shumë probleme të tjera krejtësisht arkitekturore dhe teknike.
Blockchain-i Ă«shtĂ« nĂ« thelb njĂ« mjedis komunikimi pĂ«r PVRB, ku mesazhet = transaksione. Kjo lejon qĂ« tĂ« bĂ«het njĂ« shkĂ«putje nga problemet rrjetore, mosshkarkimi i mesazheve dhe problematikat e softuerĂ«ve ndĂ«rmjetĂ«s â tĂ« gjitha kĂ«to rreziqe merr nĂ« pĂ«rsipĂ«r njĂ« rrjet tĂ« decentralizuar, dhe vlera kryesore pĂ«r PVRB Ă«shtĂ« pamundĂ«sia pĂ«r tĂ« tĂ«rhequr ose prishur njĂ« transaksion tĂ« dĂ«rguar â kjo nuk lejon pjesĂ«marrĂ«sit tĂ« heqin dorĂ« nga pjesĂ«marrja nĂ« protokoll, pĂ«rveç nĂ«se ata kanĂ« kryer njĂ« sulm tĂ« suksesshĂ«m ndaj konsensusit. NjĂ« nivel i tillĂ« sigurie Ă«shtĂ« i pranueshĂ«m, prandaj PVRB duhet tĂ« jetĂ« i qĂ«ndrueshĂ«m ndaj komplotĂ«ve tĂ« pjesĂ«marrĂ«sve nĂ« tĂ« njĂ«jtĂ«n masĂ« si zinxhiri kryesor i blockchainit. Po ashtu, kjo sugjeron se PVRB duhet tĂ« jetĂ« pjesĂ« e konsensusit, nĂ«se rrjeti Ă«shtĂ« dakordĂ«suar pĂ«r zinxhirin kryesor tĂ« blloqeve, dhe po ashtu tĂ« rĂ«nĂ« dakord mbi njĂ« rastĂ«si tĂ« vetme tĂ« ndershme si rezultat. Ose, PVRB Ă«shtĂ« thjesht njĂ« protokoll i pavarur, i realizuar me njĂ« smart contract, i punĂ«suar asinkronisht nĂ« lidhje me blockchainin dhe blloqet. TĂ« dyja mĂ«nyrat kanĂ« pĂ«rfitimet dhe disavantazhet e veta, dhe zgjedhja midis tyre Ă«shtĂ« tejet e ndĂ«rlikuar.
Dy mënyra për implementimin e PVRB
Do t'i pĂ«rshkruajmĂ« mĂ« nĂ« detaje dy variante implementimi tĂ« PVRB â versioni standalone, qĂ« funksionon duke pĂ«rdorur njĂ« smart kontratĂ« tĂ« pavarur nga blloku, dhe versionin e integruar me konsensus â tĂ« nd Build in the protocol according to which the network agrees on the blockchain and the included transactions. NĂ« tĂ« gjitha rastet do tĂ« kem parasysh motorĂ«t mĂ« tĂ« njohur tĂ« blockchain: Ethereum, EOS, dhe tĂ« gjitha ato tĂ« ngjashme me to nĂ« mĂ«nyrĂ«n e vendosjes dhe pĂ«rpunimit tĂ« smart kontratave.
Kontrata standalone
Në këtë variant, PVRB përbën një smart kontratë që merr transaksionet e prodhuesve të rastësishëm (më pas RP), i përpunon ato, kombinon rezultatet dhe, si rezultat, arrin në një vlerë të caktuar, e cila mund të merret nga çdokush nga kjo kontratë. Kjo vlerë nuk mund të ruhet drejtpërdrejt në kontratë, por mund të përfaqësohet vetëm nga të dhënat, nga të cilat mund të nxirret deterministikisht një vlerë e vetme rezultuar rastësore. Në këtë skemë, RP janë përdoruesit e blockchain-it, dhe mund të lejohet kushdo të marrë pjesë në procesin e gjenerimit.
Varianti me kontratën standalone është i mirë:
- portabiliteti (kontratate mund të transferohen nga një blockchain në tjetrin)
- thjeshtësisë në zbatim dhe testim (kontratat janë të lehta për t'u shkruar dhe testuar)
- lehtësisë në zbatimin e schemave ekonomike (është e lehtë të krijosh tokenin tënd, logjika e të cilit shërben qëllimeve PVRB)
- mundësinë për të nisur në blockchain-et ekzistuese
Ai gjithashtu ka disavantazhe:
- kufizime të mëdha në burimet gjatë llogaritjeve, vëllimi i transaksioneve dhe ndarje (në fjalë të tjera cpu/mem/io)
- kufizime në operacionet brenda kontratës (nuk janë të gjitha instrukcionet në dispozicion, është e vështirë të lidhësh bibliotekat e jashtme)
- pamundësia për të organizuar shkëmbimin e mesazheve më shpejt se sa transaksionet përfshihen në blockchain
Ky variant është i përshtatshëm për zbatimin e PVRB, i cili duhet të nisë në një rrjet ekzistues, pa përfshirë kriptografi të komplikuar dhe pa kërkuar shumë ndërveprime.
Integrimi i konsensusit
NĂ« kĂ«tĂ« variant, PVRB Ă«shtĂ« implementuar nĂ« kodin e nodit tĂ« blockchain, i integruar ose funksionon paralelisht me shkĂ«mbimin e mesazheve midis nodave tĂ« blockchain. Rezultatet e protokollit regjistrohen direkt nĂ« blloqet e prodhuara, dhe mesazhet e protokollit dĂ«rgohen pĂ«rmes rrjetit p2p midis nodave. Duke qenĂ« se protokolli ka si rezultat numra, tĂ« cilĂ«t duhet tĂ« regjistrohen nĂ« blloqe, rrjeti duhet tĂ« arrijĂ« konsensus nĂ« lidhje me ta. Kjo do tĂ« thotĂ« se mesazhet e PVRB, ashtu si dĂ«shirat, duhet tĂ« validohen nga nodat dhe tĂ« pĂ«rfshihen nĂ« blloqe, nĂ« mĂ«nyrĂ« qĂ« çdo pjesĂ«marrĂ«s i rrjetit tĂ« mund tĂ« verifikojĂ« pĂ«rmbushjen e protokollit PVRB. Kjo automatikisht na çon nĂ« njĂ« zgjidhje tĂ« qartĂ« â nĂ«se rrjeti bie dakord nĂ« konsensus pĂ«r bllokun dhe transaksionet nĂ« tĂ«, PVRB duhet tĂ« jetĂ« njĂ« pjesĂ« e konsensusit, dhe jo njĂ« protokoll i veçantĂ«. PĂ«rndryshe, mund tĂ« ndodhi njĂ« situatĂ« ku blloku Ă«shtĂ« i vlefshĂ«m nga kĂ«ndvĂ«shtrimi i konsensusit, por protokolli PVRB nuk Ă«shtĂ« respektuar, dhe nga kĂ«ndvĂ«shtrimi i PVRB, blloku nuk mund tĂ« pranohet. Prandaj, nĂ«se zgjidhet varianti 'integruar nĂ« konsensus', PVRB bĂ«het njĂ« pjesĂ« e rĂ«ndĂ«sishme e konsensusit.
Duke pĂ«rshkruar implementimet PVRB nĂ« nivelin e konsensusit nĂ« rrjet, nuk duhet nĂ« asnjĂ« mĂ«nyrĂ« tĂ« anashkalohet çështja e pĂ«rfundimit. PĂ«rfundimi Ă«shtĂ« njĂ« mekanizĂ«m qĂ« pĂ«rdoret nĂ« konsensuset e caktuara, i cili fikson njĂ« bllok (dhe zinxhirin qĂ« e çon atje) qĂ« Ă«shtĂ« pĂ«rfundimtar dhe kurrĂ« nuk do tĂ« hiqet, edhe nĂ«se shfaqet njĂ« fork paralel. PĂ«r shembull, nĂ« Bitcoin nuk ekziston njĂ« mekanizĂ«m tĂ« tillĂ« â nĂ«se publikohet njĂ« zinxhir me njĂ« kompleksitet mĂ« tĂ« madh, ai do tĂ« zĂ«vendĂ«sojĂ« çdo zinxhir mĂ« pak tĂ« ndĂ«rlikuar, pa marrĂ« parasysh gjatĂ«si tĂ« zinxhirĂ«ve. NdĂ«rsa nĂ« EOS, pĂ«r shembull, blloqet pĂ«rfundimtare janĂ« tĂ« ashtuquajtura Last Irreversible Blocks, qĂ« shfaqen mesatarisht çdo 432 blloqe (12*21 + 12*15, votimi paraprak + angazhimi paraprak). Ky proces Ă«shtĂ« nĂ« thelb njĂ« pritje pĂ«r 2/3 e nĂ«nshkrimeve tĂ« prodhuesve tĂ« bllokut (mĂ« pas BP). Kur shfaqen fork-e qĂ« janĂ« mĂ« tĂ« vjetra se LIB-i i fundit ato thjesht hidhen poshtĂ«. Ky mekanizĂ«m garanton qĂ« transaksioni Ă«shtĂ« pĂ«rfshirĂ« nĂ« bllokçain dhe kurrĂ« nuk do tĂ« hiqet, pavarĂ«sisht burimeve qĂ« mund tĂ« ketĂ« sulmuesi. Po ashtu, blloqet pĂ«rfundimtare janĂ« blloqet e nĂ«nshkruara nga 2/3 BP nĂ« Hyperledger, Tendermint dhe konsensuse tĂ« tjera tĂ« bazuara nĂ« pBFT. Gjithashtu, protokolli pĂ«r tĂ« siguruar pĂ«rfundimin ka kuptim tĂ« bĂ«het njĂ« shtresĂ« mbi konsensusin, pasi ai mund tĂ« punojĂ« asinkronisht me prodhimin dhe publikimin e blloqeve. KĂ«tu Ă«shtĂ« njĂ« shembull i mirĂ« pĂ«r finalitetin nĂ« Ethereum.
Finaliteti Ă«shtĂ« jashtĂ«zakonisht i rĂ«ndĂ«sishĂ«m pĂ«r pĂ«rdoruesit, tĂ« cilĂ«t pa tĂ« mund tĂ« bĂ«hen viktima tĂ« sulmit âdouble spendâ, kur BP âmbanâ blloqet dhe i publikojnĂ« ato pasi rrjeti âka parĂ«â njĂ« transaksion tĂ« mirĂ«. NĂ«se nuk ka finalitet, forku i publikuar zĂ«vendĂ«son bllokun me transaksionin âtĂ« mirĂ«â me njĂ« tjetĂ«r nga forku âi keqâ, nĂ« tĂ« cilin ato tĂ« njĂ«jtat fonde transferohen nĂ« adresĂ«n e sulmuesit. NĂ« rastin e PVRB, kĂ«rkesat pĂ«r finalitet bĂ«hen edhe mĂ« strikte, pasi ndĂ«rtimi i forkĂ«ve pĂ«r PVRB nĂ«nkupton mundĂ«sinĂ« qĂ« sulmuesi tĂ« pĂ«rgatisĂ« disa variante tĂ« rastĂ«sisĂ« me qĂ«llim pĂ«r tĂ« publikuar atĂ« mĂ« tĂ« favorshĂ«m pĂ«r tĂ« dhe pĂ«r tĂ« kufizuar kohĂ«n e mundshme tĂ« sulmit â njĂ« zgjidhje e mirĂ«.
Prandaj opsioni mĂ« i mirĂ« Ă«shtĂ« tĂ« kombinohen PVRB dhe finaliteti nĂ« njĂ« protokoll â kĂ«shtu blloku i finalizuar = rastĂ«sia e finalizuar, dhe kjo Ă«shtĂ« pikĂ«risht ajo qĂ« duhej arritur. Tani lojtarĂ«t do tĂ« marrin rastĂ«sinĂ« e garantuar pas N sekondash dhe mund tĂ« jenĂ« tĂ« sigurt se rrotullimi i saj ose ri-renditja nuk Ă«shtĂ« e mundur.
Opsioni me consensus-integrated është i mirë:
- mundĂ«sisĂ« pĂ«r realizimin asinkron nĂ« lidhje me prodhimin e bllokĂ«ve â blloket prodhohen si zakonisht, por njĂ«kohĂ«sisht mund tĂ« punojĂ« protokoli PVRB, i cili prodhon raste rastĂ«sore pĂ«r çdo bllok.
- mundësisë për të implementuar madje kriptografi të avancuar, pa kufizime të vendosura ndaj kontratave inteligjente.
- mundësisë për të organizuar këmbime mesazhi më shpejt se transaksionet që përfshihen në bllokçen, për shembull, një pjesë e protokollit mund të punojë midis nodave pa shpërndarjen e mesazheve në rrjet.
Ai gjithashtu ka disavantazhe:
- vĂ«shtirĂ«sive gjatĂ« testeve dhe zhvillimit â do tĂ« duhet tĂ« imitojmĂ« gabimet e rrjetit, nodet e humbura, hardfork-et e rrjetit.
- gabimet në realizim kërkojnë hardfork të rrjetit.
Të dyja mënyrat e implementimit të PVRB kanë të drejtë të ekzistojnë, por realizimi në kontratat inteligjente në blockchainet moderne është ende mjaft i kufizuar në burimet kompjuterike, dhe çdo kalim në kriptografi serioze shpesh është thjesht i pamundur. Dhe na nevojitet kriptografia serioze, siç do të demonstrohet më tej. Megjithatë, ky problem është dukshëm temporal, kriptografia serioze në kontrata është e nevojshme për të zgjidhur një numër të madh problemesh, dhe, gradualisht po shfaqet (p.sh., kontratat sistemike për zkSNARKs në Ethereum)
Blockchain-i, i cili ofron njĂ« kanal transparent dhe tĂ« besueshĂ«m pĂ«r shkĂ«mbimin e mesazheve tĂ« protokollit, nuk e bĂ«n kĂ«tĂ« falas. Ădo protokoll i decentralizuar duhet tĂ« konsiderojĂ« mundĂ«sinĂ« e sulmit Sybil, çdo veprim mund tĂ« bĂ«het nga forca tĂ« shumta llogarish tĂ« bashkuara, prandaj nĂ« dizajnimin e tij duhet marrĂ« parasysh kapaciteti i sulmuesve pĂ«r tĂ« krijuar numra tĂ« jashtĂ«zakonshĂ«m pjesĂ«marrĂ«sish tĂ« protokollit qĂ« veprojnĂ« nĂ« marrĂ«veshje.
PVRB dhe variabel për bllokun.
Nuk kam gĂ«njyer kur thashĂ« se nuk ka PVRB tĂ« mirĂ«, tĂ« verifikuar nga shumĂ« aplikacione tĂ« lojĂ«rave, tĂ« implementuar nĂ« blockchain deri tani. Si ndodhi atĂ«herĂ« qĂ« ka kaq shumĂ« aplikacione lojĂ«rash nĂ« Ethereum dhe EOS? MĂ« habit ashtu siç ju habit edhe juve, si Ă«shtĂ« e mundur qĂ« nĂ« njĂ« mjedis tĂ«rĂ«sisht tĂ« determinueshĂ«m tĂ« ekzistojnĂ« kaq shumĂ« ârastĂ«siâ tĂ« qĂ«ndrueshme?
MĂ«nyra mĂ« e preferuar pĂ«r tĂ« marrĂ« rastĂ«si nĂ« blockchain Ă«shtĂ« tĂ« merret ndonjĂ« informacion âtĂ« paparashikueshĂ«mâ nga njĂ« bllok, dhe mbi bazĂ«n e tij tĂ« krijohet rastĂ«si â thjesht duke kaluar njĂ« ose disa vlera nĂ« hash. NjĂ« artikull i mirĂ« pĂ«r problemet e tillĂ«. Mund tĂ« marrĂ«ni ndonjĂ« nga vlerat âtĂ« paparashikueshmeâ nĂ« bllok, pĂ«r shembull hash-in e bllokut, numrin e transaksioneve, vĂ«shtirĂ«sinĂ« e rrjetit dhe vlera tĂ« tjera, tĂ« cilat nuk dijnĂ« paraprakisht. MĂ« pas sigurisht se duhet tĂ« krijoni hash-in e tyre, njĂ« ose disa, dhe, teorikisht, duhet tĂ« rezultojĂ« njĂ« rastĂ«si e vĂ«rtetĂ«. Mund ta shtoni madje nĂ« whitepaper-in tuaj se skema juaj Ă«shtĂ« âpost-quantum secureâ (sepse ekzistojnĂ« funksione hash qĂ« janĂ« tĂ« sigurta ndaj kuantumit :)).
Por për fat të keq, as funksionet hash post-quantum secure nuk janë të mjaftueshme. Sekreti qëndron në kërkesat për PVRB, le të këmbim në to nga artikulli i mëparshëm:
- Rezultati duhet të ketë një shpërndarje që provon të jetë uniforme, pra të bazohet në kriptografinë e qëndrueshme që provohet.
- Nuk është e mundur të kontrolloni asnjë nga bitët e rezultatit. Si pasojë, rezultati nuk mund të parashikohet paraprakisht.
- Nuk është e mundur të sabotosh protokollin e gjenerimit përmes mos pjesëmarrjes në protokoll ose duke e ngarkuar rrjetin me mesazhe sulmuese.
- Të gjitha të mësipërmet duhet të jenë të forta ndaj komplotit të një numri të pranueshëm të pjesëmarrësve të pandershëm në protokoll (për shembull 1/3 e pjesëmarrësve).
Në këtë rast respektohet vetëm kërkesa 1, dhe kërkesa 2 nuk respektohet. Duke rishikuar vlera të paparashikueshme nga bloku, ne do të kemi një shpërndarje të barabartë dhe rastësi të mira. Por BP ka të paktën mundësinë "të publikojë blokun ose jo". Kështu që BP mund të zgjedhë të paktën nga DY variante të rastësisë: "e tij" dhe atë që rezulton, nëse blloku e bën dikush tjetër. BP mund të "shikojë" paraprakisht se çfarë do të rezultojë, nëse ai publikon bllokun, dhe thjesht merr vendimin ta bëjë ose jo. Kështu, duke luajtur, për shembull, në "çift-pak" ose "të kuqe/të zeza" në ruletë, ai mund të publikojë bllokun vetëm nëse sheh fitimin. Kjo gjithashtu e bën strategjinë e përdorimit, për shembull, të hash-it të bllokut "nga e ardhmja" të papërdorshme. Në këtë rast thuhet se "do të përdoret rastësia, e cila rezulton nga hashimi i të dhënave aktuale dhe hash-it të bllokut të ardhshëm me një lartësi, për shembull, N + 42, ku N është lartësia aktuale e bllokut. Kjo e forcon pak skemën, por përsëri i lejon BP-së, edhe në të ardhmen, të zgjedhë të mbajë bllokun ose ta publikojë.
Soft BP në këtë rast komplikohet, por jo shumë. Thjesht gjatë validimit dhe përfshirjes së transaksionit në bllok bëhet një kontroll i shpejtë për të parë nëse do të ketë fitim, dhe ndoshta përcaktimi i një parametri të transaksionit për të arritur një probabilitet të lartë fitoresh. Megjithatë, kapja e një BP të zgjuar, që bën një manipulim të tillë, është praktikisht e pamundur; çdo herë mund të përdoren adresa të reja dhe të fitohet pak nga pak, pa ngjallur dyshime.
Prandaj, metodat që përdorin informacionin nga blloku nuk janë të përshtatshme si një zbatim universik i PVRB. Në një version të kufizuar, me kufizime në madhësitë e basteve, kufizime mbi numrin e lojtarëve dhe/ose regjistrimin KYC (për të mos i lejuar një lojtari të përdorë disa adresa), këto skema mund të funksionojnë për lojëra të vogla, por jo më shumë se kaq.
PVRB dhe commit-reveal.
MirĂ«, faleminderit pĂ«r hashing-un dhe ndonjĂ«herĂ« pĂ«rparĂ«sinĂ« relative tĂ« hash-it tĂ« blokut dhe faktorĂ«ve tĂ« tjerĂ«. NĂ«se zgjidhet problemi i front-running-ut tĂ« minatorĂ«ve, duhet tĂ« rezultojĂ« diçka mĂ« tĂ« mirĂ«. Le tĂ« shtojmĂ« pĂ«rdoruesit nĂ« kĂ«tĂ« skemĂ« â le tĂ« ndikojnĂ« gjithashtu nĂ« rastĂ«sinĂ«: çdo punonjĂ«s i shĂ«rbimit tĂ« tregtisĂ« do t'ju thotĂ« se ajo qĂ« Ă«shtĂ« mĂ« e rastĂ«sishme nĂ« sistemet IT janĂ« veprimet e pĂ«rdoruesve đ
NjĂ« skemĂ« naive, kur pĂ«rdoruesit thjesht dĂ«rgojnĂ« numra rastĂ«sorĂ« dhe rezultati llogaritet si, pĂ«r shembull, njĂ« hash nga shuma e tyre, nuk funksionon. NĂ« kĂ«tĂ« rast, lojtari i fundit mund tĂ« kontrollojĂ« rezultatin duke zgjedhur rastĂ«sorin e tij. Prandaj, pĂ«rdoret njĂ« model shumĂ« tĂ« njohur si commit-reveal. PjesĂ«marrĂ«sit sĂ« pari dĂ«rgojnĂ« hash-et e rastĂ«sorĂ«ve tĂ« tyre (commit-e), dhe mĂ« pas zbulojnĂ« vetĂ« rastĂ«sorĂ«t (reveal-e). Faza ârevealâ fillon vetĂ«m pasi tĂ« jenĂ« mbledhur commit-et e nevojshme, kĂ«shtu qĂ« pjesĂ«marrĂ«sit mund tĂ« dĂ«rgojnĂ« saktĂ«sisht rastĂ«sorin, hash-i i tĂ« cilit u dĂ«rgua mĂ« parĂ«. Tani le tĂ« kombinojmĂ« tĂ« gjitha kĂ«tĂ« me parametrat e bllokut, dhe Ă«shtĂ« mĂ« mirĂ« tĂ« marrim nga e ardhmja (rastĂ«sori do tĂ« jetĂ« i njohur vetĂ«m nĂ« njĂ« nga blloqet e ardhshme), dhe voila â rastĂ«sori Ă«shtĂ« gati! Tani çdo lojtar ndikon nĂ« rastĂ«sorin pĂ«rfundimtar dhe mund tĂ« âpĂ«rfitojĂ«â nga BP i keq, duke e bllokuar rastĂ«sorin e tij me rastĂ«sorin e tij, i cili nuk dihet paraprakisht... Gjithashtu, mund tĂ« shtojmĂ« mbrojtje nga sabotimi i protokollit pĂ«rmes moszbulimit nĂ« fazĂ«n e reveal â duke kĂ«rkuar thjesht qĂ« me commit-in tĂ« bashkĂ«ngjitet njĂ« shumĂ« â njĂ« depozitĂ« tĂ« sigurimit, e cila do tĂ« kthehet vetĂ«m gjatĂ« procedurĂ«s reveal. NĂ« kĂ«tĂ« rast, tĂ« bĂ«sh commit dhe tĂ« mos bĂ«sh reveal do tĂ« jetĂ« e pavarur.
Ishte një përpjekje e mirë, dhe skema të tilla ekzistojnë edhe në DApp-et e lojërave, por fatkeqësisht, kjo përsëri nuk mjafton. Tani rezultati mund të ndikojë jo vetëm nga minerët, por edhe nga çdo pjesëmarrës në protokoll. Të kontrollosh vetë vlerën është ende e mundur, me një shkallë më të vogël variabiliteti dhe me pagesë, por, ashtu si në rastin e minerit, nëse rezultatet e shortit kanë më shumë vlerë sesa paga për pjesëmarrje në protokollin PVRB, atëherë random-producer (RP) mund të vendosë nëse të bëjë reveal dhe ende mund të zgjedhë nga të paktën dy variante randomi.
Por tani ka mundĂ«si pĂ«r tĂ« ndĂ«shkuar ata qĂ« bĂ«jnĂ« commit dhe nuk bĂ«jnĂ« reveal, dhe kjo skemĂ« do tĂ« jetĂ« e dobishme. ThjeshtĂ«sia e saj Ă«shtĂ« njĂ« avantazh i rĂ«ndĂ«sishĂ«m â protokollet mĂ« serioze kĂ«rkojnĂ« llogaritje shumĂ« mĂ« tĂ« fuqishme.
PVRB dhe nënshkrimet e përcaktuara.
Ka njĂ« mĂ«nyrĂ« tjetĂ«r pĂ«r ta bĂ«rĂ« RP tĂ« sigurojĂ« njĂ« numĂ«r pseudo-rastĂ«sor, nĂ« tĂ« cilin ai nuk mund tĂ« ndikojĂ«, nĂ«se i ofrohet "prototipi" â kjo Ă«shtĂ« njĂ« nĂ«nshkrim deterministik. NjĂ« shembull i tillĂ« nĂ«nshkrimi Ă«shtĂ« RSA, dhe nuk Ă«shtĂ« ECS. NĂ«se RP ka njĂ« çift çelesh: RSA dhe ECC, dhe ai nĂ«nshkruan njĂ« vlerĂ« me çelĂ«sin e tij privat, atĂ«herĂ« nĂ« rastin e RSA ai do tĂ« ketĂ« NJĂ DHE VETĂM NJĂ nĂ«nshkrim, ndĂ«rsa nĂ« rastin e ECS â ai mund tĂ« gjenerojĂ« ndonjĂ« numĂ«r tĂ« ndryshĂ«m nĂ«nshkrimesh tĂ« vlefshme. Kjo ndodh sepse gjatĂ« krijimit tĂ« nĂ«nshkrimit ECS pĂ«rdoret njĂ« numĂ«r rastĂ«sor, qĂ« zgjidhet nga nĂ«nshkruesi, dhe ai mund tĂ« zgjidhet si tĂ« dush, duke i dhĂ«nĂ« nĂ«nshkruesit mundĂ«sinĂ« tĂ« zgjedhĂ« njĂ« nga disa nĂ«nshkrim. NĂ« rastin e RSA: "njĂ« vlerĂ« hyrĂ«se" + "njĂ« çift çelesh" = "njĂ« nĂ«nshkrim". Nuk Ă«shtĂ« e mundur tĂ« parashikosh se cila do tĂ« jetĂ« nĂ«nshkrimi i njĂ« RP tjetĂ«r, prandaj PVRB me nĂ«nshkrime deterministike mund tĂ« organizohet pĂ«rmes kombinimit tĂ« nĂ«nshkrimeve RSA tĂ« disa pjesĂ«marrĂ«sve, tĂ« cilĂ«t kanĂ« nĂ«nshkruar tĂ« njĂ«jtĂ«n vlerĂ«. PĂ«r shembull â rastĂ«si e mĂ«parshme. NĂ« njĂ« skemĂ« tĂ« tillĂ« kursehen shumĂ« burime, pasi nĂ«nshkrimet pĂ«rbĂ«jnĂ« njĂ«kohĂ«sisht dhe njĂ« konfirmim tĂ« saktĂ«sisĂ« sĂ« sjelljes sipas protokollit, dhe njĂ« burim rastĂ«sor.
Megjithatë, edhe me nënshkrime të determinuara, skema vazhdon të jetë e pambrojtur ndaj problemit të "aktorit të fundit". Pjesëmarrësi i fundit vazhdon të ketë mundësinë të vendosë nëse do të publikohet nënshkrimi i tij apo jo, duke kontrolluar kështu rezultatin. Mund të përmirësohet skema, duke shtuar hash-e të bllokove, duke realizuar raunde, për të bërë të pamundshme parashikimin e rezultatit të mëparshëm, por të gjitha këto teknikë, madje duke marrë parasysh shumë përmirësime, sërish lënë të pazgjidhur problemin e ndikimit të një pjesëmarrësi në rezultatin kolektiv në një ambient të pa besueshëm dhe mund të funksionojnë vetëm në kushte kufizimesh ekonomike dhe kohore. Për më tepër, madhësia e çelësave RSA (1024 dhe 2048 bit) është mjaft e madhe, ndërsa madhësia për transaksionet në blockchain është një parametr i jashtëzakonshëm. Dukshëm, nuk do të jetë e thjeshtë të zgjidhet problemi, le të vazhdojmë më tej.
Schemat PVRB dhe ndarjen sekrete
Në kriptografi ekzistojnë skema që mund të lejojnë rrjetin të arrijë një vlerë të vetme PVRB, ndërsa këto skema janë të qëndrueshme ndaj çdo veprimi të keq i një pjese të pjesëmarrësve. Një nga protokollet e dobishme, me të cilat duhet të njihemi, është skema e ndarjes së sekreteve të Shamir. Ajo shërben për të ndarë një sekret (p.sh., një çelës sekret) në disa pjesë dhe për t'i shpërndarë këto pjesë N pjesëmarrësve. Sekreti shpërndahet në një mënyrë që për ta rikuperuar, mjaftojnë M pjesë nga N, dhe ato mund të jenë çfarëdo M pjesësh. Nëse e shikojmë në një mënyrë më të thjeshtë, duke pasur një grafik të një funksioni të panjohur, pjesëmarrësit ndajnë pika në grafik, dhe pas marrjes së M pikave, e gjithë funksioni mund të rikuperohet.
Një shpjegim i mirë jepet në dhe për ta luajtur praktikisht, për të luajtur protokollin në mendje është e dobishme në faqen.
NĂ«se skema FSSS (Financi Fiat-Shamir) do tĂ« aplikonte nĂ« formĂ«n e saj tĂ« pastĂ«r â kjo do tĂ« ishte njĂ« PVRB e pathyeshme. NĂ« variantin mĂ« tĂ« thjeshtĂ«, protokolli mund tĂ« duket kĂ«shtu:
- Ădo pjesĂ«marrĂ«s gjeneron randomin e tij dhe shpĂ«rndan pjesĂ«t nga ai tek pjesĂ«marrĂ«sit e tjerĂ«.
- Ădo pjesĂ«marrĂ«s zbulon pjesĂ«n e tij tĂ« sekreteve tĂ« pjesĂ«marrĂ«sve tĂ« tjerĂ«
- Nëse një pjesëmarrës ka mbledhur më shumë M shares, atëherë numri i këtij pjesëmarrësi mund të llogaritet, dhe ai do të jetë unik, pavarësisht nga grupi i pjesëmarrësve të zbuluar
- Kombinimi i random-ëve të zbuluar është PVRB që kërkohet
Këtu një pjesëmarrës i veçantë nuk ndikon në rezultatet e protokollit, përveç rasteve kur vetëm prej tij varet arritja e threshold-it të zbulesës së random-ave. Prandaj, ky protokoll, me prani të shumës së nevojshme të punonjësve sipas protokollit dhe me RP të disponueshëm punon, duke realizuar kërkesat për qëndrueshmërinë kriptografike, dhe duke qenë i qëndrueshëm ndaj problemit "last actor".
Kjo mund të ishte alternativa ideale, kjo skemë PVRB mbi bazën e ndarjes së sekreteve të Fiat-Shamir është përshkruar, për shembull, në artikuj. Por, siç u tha më parë, nëse përpiqemi ta aplikojmë atë drejtpërdrejt në blockchain, shfaqen kufizime teknike. Ja një shembull i realizimit të testit të protokollit në smart kontratën EOS dhe pjesa më e rëndësishme e saj është kontrolli i share të publikuar nga pjesëmarrësi: . Nga kodi duket se validimi i proof-it kërkon disa shumëzime skalarë, dhe numrat përdoren shumë të mëdha. Në këtë rast, duhet të kuptohet se në blockchain verifikimi ndodh në momentin kur block-producer proceson transaksionin, dhe çdo pjesëmarrës duhet të jetë në gjendje të verifikojë lehtësisht saktësinë e protokollit, prandaj kërkesat për shpejtësinë e funksionit të verifikimit janë shumë të rënda. Në këtë variant, zgjidhja rezultoi e papranueshme, pasi verifikimi nuk përputhej me kufizimin për transaksionin (0.5 sek).
Efikasiteti i verifikimit Ă«shtĂ« njĂ« nga kĂ«rkesat kryesore pĂ«r pĂ«rdorimin e çdo skemash tĂ« avancuara kriptografike nĂ« blockchain. Krijimi i proof-eve, pĂ«rgatitja e mesazheve â kĂ«to procedura mund tĂ« kryhen off-chain dhe tĂ« realizohen nĂ« kompjuterĂ« me performancĂ« tĂ« lartĂ«, por nuk do tĂ« jetĂ« e mundur tĂ« anashkalohet verifikimi â kjo Ă«shtĂ« njĂ« kĂ«rkesĂ« tjetĂ«r e rĂ«ndĂ«sishme pĂ«r PVRB.
PVRB dhe nënshkrimet threshold
Pas ndihmĂ«s me skemĂ«n e ndarjes sĂ« sekreteve, ne zbuluam njĂ« klas tĂ« tĂ«rĂ« protokollesh tĂ« lidhura me fjalĂ«n kyçe âthresholdâ. Kur pĂ«r tĂ« zbuluar disa informacione kĂ«rkohet pjesĂ«marrja e M pjesĂ«marrĂ«sve tĂ« ndershĂ«m nga N, dhe grupi i pjesĂ«marrĂ«sve tĂ« ndershĂ«m mund tĂ« jetĂ« njĂ« nĂ«nmjeshtĂ«r i çfarĂ«doshĂ«m i N, flitet pĂ«r skemat âthresholdâ. KĂ«to skema lejojnĂ« tĂ« merren me problemin e âaktorit tĂ« funditâ, tani nĂ«se sulmuesi nuk hap pjesĂ«n e tij tĂ« sekreti, njĂ« pjesĂ«marrĂ«s tjetĂ«r i ndershĂ«m do ta bĂ«jĂ« atĂ«. KĂ«to skema lejojnĂ« tĂ« rĂ«mbehet njĂ« vlerĂ« tĂ« vetme, edhe nĂ« rastin e sabotazhit tĂ« protokollit nga njĂ« pjesĂ« e pjesĂ«marrĂ«sve.
Kombinimi i nĂ«nshkrimeve deterministe dhe skemave threshold ka lejuar zhvillimin e njĂ« skeme shumĂ« tĂ« pĂ«rshtatshme dhe premtuese pĂ«r realizimin e PVRB â kĂ«to janĂ« nĂ«nshkrime deterministe threshold. Ja pĂ«r aplikime tĂ« ndryshme tĂ« nĂ«nshkrimeve threshold, dhe ja njĂ« tjetĂ«r e mirĂ« nga Dash.
NĂ« artikullin e fundit pĂ«rshkruhen nĂ«nshkrimet BLS (BLS shĂ«nohet si Boneh-Lynn-Shacham, artikuj, tĂ« cilĂ«t kanĂ« njĂ« cilĂ«si shumĂ« tĂ« rĂ«ndĂ«sishme dhe jashtĂ«zakonisht tĂ« pĂ«rshtatshme pĂ«r programuesit â çelĂ«sat publikĂ«, sekretĂ«, çelĂ«sat dhe nĂ«nshkrimet BLS mund tĂ« kombinohen me njĂ«ri-tjetrin me ndihmĂ«n e operacioneve matematikore tĂ« thjeshta, ndĂ«rsa kombinimet e tyre mbeten çelĂ«sa dhe nĂ«nshkrime tĂ« vlefshme, duke lejuar agregimin e lehtĂ« tĂ« shumĂ« nĂ«nshkrimeve nĂ« njĂ« dhe shumĂ« çelĂ«sa publikĂ« nĂ« njĂ«. Ato gjithashtu kanĂ« deterministikĂ« dhe pĂ«r tĂ« njĂ«jtat tĂ« dhĂ«na hyrese japin tĂ« njĂ«jtin rezultat. FalĂ« kĂ«saj cilĂ«sie, kombinimet e nĂ«nshkrimeve BLS janĂ« vetĂ« çelĂ«sa tĂ« vlefshĂ«m, çka lejon realizimin e njĂ« varianti, nĂ« tĂ« cilin M nga N pjesĂ«marrĂ«sit prodhojnĂ« njĂ« dhe vetĂ«m njĂ« nĂ«nshkrim, i cili Ă«shtĂ« i determinueshĂ«m, i verifikueshĂ«m publikisht dhe i paparashikueshĂ«m deri sa tĂ« zhbllokohet nga pjesĂ«marrĂ«si i M-tĂ«.
Në skemën me nënshkrime BLS threshold, çdo pjesëmarrës nënshkruan me ndihmën e BLS diçka (për shembull, rastin e mëparshëm), dhe nënshkrimi i përbashkët threshold është rastin që kërkohet. Vetitë kriptografike të nënshkrimeve BLS i përmbushin kërkesat për cilësinë e rastit, pjesa threshold mbron nga "aktorin e fundit", dhe kombinueshmëria unike e çelësave lejon realizimin e shumë algoritmeve interesante, të cilat lejojnë, për shembull, agregimin efikas të mesazheve të protokollit.
Pra, nëse po ndërtoni PVRB në bllokun tuaj, ka një probabilitet të madh që do të arrini në skemën BLS threshold signatures, e cila përdoret tashmë nga disa projekte. Për shembull, DFinity ( benchmarku që implementon skemën, dhe shembulli i realizimit të ndarjes sekrete të verifikueshme), ose Keep.network (ja, ndodhet random beacon , kështu që kontraktit inteligjent që shërben protokollin).
Implementimi i PVRB
Fatkeq, ende nuk shohim një protokoll të gatshëm, i zbatuar në bllokadat PVRB, që ka dëshmuar sigurinë dhe qëndrueshmërinë e tij. Edhe pse protokollet janë gati, është e vështirë t'i aplikosh ato në zgjidhjet ekzistuese nga ana teknike. Për sistemet e centralizuara, PVRB nuk ka kuptim, ndërsa ato të decentralizuara janë të kufizuara në të gjitha burimet llogaritëse: CPU, memorie, ruajtje, I/O. Projektimi i PVRB është kombinimi i protokolleve të ndryshme, për të krijuar diçka që përmbush të gjitha kërkesat, për të arritur të paktën ndonjë bllokadë funksionale. Një protokoll llogarit më efikas, por kërkon më shumë mesazhe ndërmjet RP, ndërsa tjetri kërkon shumë pak mesazhe, por krijimi i prova mund të jetë një detyrë që zgjat disa minuta, madje edhe orë.
Do të rendis faktorët që duhet të merrni parasysh kur zgjidhni një PVRB të cilësisë:
- Qëndrueshmëria kriptografike. PVRB juaj duhet të jetë strikte unbiasable, pa mundësi për të kontrolluar një bit të vetëm. Në disa skema kjo nuk është kështu, prandaj thërrisni një kriptograf.
- Problemi âlast actorâ. PVRB juaj duhet tĂ« jetĂ« i qĂ«ndrueshĂ«m ndaj sulmeve, kur sulmuesi, qĂ« kontrollon njĂ« ose mĂ« shumĂ« RP, mund tĂ« zgjedhĂ« njĂ« nga dy mundĂ«sitĂ« e rezultatit.
- Problemi i sabotazhit të protokollit. PVRB juaj duhet të jetë i qëndrueshëm ndaj sulmeve, kur sulmuesi, që kontrollon një ose më shumë RP, vendos nëse do të jetë rastësor apo jo dhe mund të ndikojë me siguri, ose me një mundësi të caktuar mbi këtë.
- Problemi i numrit të mesazheve. RP-të tuaja duhet të dërgojnë në blockchain minimumin e mesazheve dhe të shmangin sa më shumë veprimet sinkronike si situatat "dërgova disa informacione, po pres përgjigje nga një pjesëmarrës i caktuar". Në rrjetet p2p, sidomos ato gjeografikisht të shpërndara, nuk duhet të llogaritni në përgjigje të shpejtë.
- Problemi i kompleksitetit të llogaritjes. Verifikimi i çdo faze të PVRB në zinxhir duhet të jetë extremisht i lehtë, pasi e kryejnë të gjithë klientët e plotë të rrjetit. Nëse realizimi bëhet me anë të kontratës inteligjente, kërkesat për shpejtësi janë shumë të forta.
- Problemi i aksesueshmërisë dhe liveness. PVRB juaj duhet të përpiqet të jetë i qëndrueshëm ndaj situatave kur pjesa e rrjetit është bërë e paarritshme për një kohë dhe disa RP thjesht kanë ndaluar së funksionuari.
- Problemi i konfigurimit tĂ« besueshĂ«m dhe shpĂ«rndarjes fillestare tĂ« çelĂ«save. NĂ«se PVRB juaj pĂ«rdor konfigurimin primar tĂ« protokollit, atĂ«herĂ« kjo Ă«shtĂ« njĂ« histori tjetĂ«r e madhe dhe serioze. Ja . NĂ«se pjesĂ«marrĂ«sit duhet tĂ« njoftojnĂ« njĂ«ri-tjetrin pĂ«r çelĂ«sat e tyre para fillimit tĂ« protokollit â kjo Ă«shtĂ« gjithashtu njĂ« problem, nĂ«se pĂ«rbĂ«rja e pjesĂ«marrĂ«sve ndryshon
- Problemet e zhvillimit. Prania e bibliotekave në gjuhët përkatëse, siguria dhe performanca e tyre, publikimi, testet e komplikuara etj.
NĂ« threshold BLS ka njĂ« problem tĂ« rĂ«ndĂ«sishĂ«m â pĂ«rpara se tĂ« fillojnĂ« punĂ«n, pjesĂ«marrĂ«sit duhet patjetĂ«r tĂ« ndajnĂ« çelĂ«sat me njĂ«ri-tjetrin, duke organizuar njĂ« grup brenda krijohet njĂ« threshold. Kjo do tĂ« thotĂ« qĂ«, si njĂ« minimum, do tĂ« duhet tĂ« pritet njĂ« rreth shkĂ«mbimi nĂ« njĂ« rrjet tĂ« decentralizuar, dhe duke e marrĂ« parasysh qĂ« gjenerimi i rastĂ«sishĂ«m, pĂ«r shembull, Ă«shtĂ« i nevojshĂ«m nĂ« lojĂ«ra, praktikisht nĂ« kohĂ« reale, kjo do tĂ« thotĂ« qĂ« sabotimi i protokollit Ă«shtĂ« i mundshĂ«m nĂ« kĂ«tĂ« fazĂ«, dhe pĂ«rfitimet e skemĂ«s sĂ« threshold humbasin. Ky problem Ă«shtĂ« mĂ« i lehtĂ« se i mĂ«parshmi, por prapĂ«seprapĂ« kĂ«rkon zhvillimin e njĂ« procedure tĂ« veçantĂ« pĂ«r formimin e grupeve threshold, e cila do tĂ« duhet tĂ« mbrohet ekonomikisht, pĂ«rmes depozitave dhe konfiskimit (slashing) tĂ« fondeve nga pjesĂ«marrĂ«sit qĂ« nuk ndjekin protokollin. Po ashtu, verifikimi i BLS me njĂ« nivel tĂ« pranueshĂ«m sigurie thjesht nuk kapet, pĂ«r shembull, brenda njĂ« transaksioni standard tĂ« EOS ose Ethereum â thjesht nuk ka mjaft kohĂ« pĂ«r verifikim. Kodi i kontratave Ă«shtĂ« WebAssembly ose EVM, i ekzekutuar nga njĂ« makinĂ« virtuale. Funksionet kriptografike nuk janĂ« tĂ« realizuara native (pĂ«r momentin), dhe punojnĂ« disa herĂ« mĂ« ngadalĂ« se bibliotekat kriptografike standarde. ShumĂ« protokolle nuk janĂ« tĂ« pĂ«rshtatshme sipas kĂ«rkesave vetĂ«m duke u bazuar nĂ« volumin e çelĂ«save, pĂ«r shembull, 1024 dhe 2048 bit pĂ«r RSA, 4-8 herĂ« mĂ« shumĂ« se nĂ«nshkrimi standard i transaksionit nĂ« Bitcoin dhe Ethereum.
Luan njĂ« rol dhe ka njĂ« numĂ«r implementation nĂ« gjuhĂ« tĂ« ndryshme programimi â tĂ« cilat janĂ« pak, sidomos pĂ«r protokollet e reja. Opcioni i integrimit nĂ« konsensus kĂ«rkon qĂ« protokolli tĂ« shkruhet nĂ« gjuhĂ«n e platformĂ«s, prandaj do tĂ« duhet tĂ« kĂ«rkoni kod nĂ« Go pĂ«r geth, nĂ« Rust pĂ«r Parity, dhe nĂ« C++ pĂ«r EOS. Kodin nĂ« JavaScript do tĂ« duhet tĂ« kĂ«rkojnĂ« tĂ« gjithĂ«, dhe pasi JavaScript dhe kriptografia nuk janĂ« miq tĂ« ngushtĂ«, WebAssembly do tĂ« ndihmojĂ«, i cili tani me siguri pretendohet si standardi i ardhshĂ«m i rĂ«ndĂ«sishĂ«m nĂ« internet.
PĂ«rfundimi
Shpresoj qĂ« nĂ« tĂ« kaluarĂ«n jam munduar t'ju bind se gjenerimi i numrave tĂ« rastĂ«sishĂ«m nĂ« bllokchain Ă«shtĂ« kritikisht i rĂ«ndĂ«sishĂ«m pĂ«r shumĂ« aspekte tĂ« jetĂ«s sĂ« rrjeteve tĂ« decentralizuara, dhe me kĂ«tĂ« artikull tregova se ky detyrĂ« Ă«shtĂ« jashtĂ«zakonisht ambicioze dhe e vĂ«shtirĂ«, por zgjidhje tĂ« mira tashmĂ« ekzistojnĂ«. NĂ« tĂ« vĂ«rtetĂ«, dizajni pĂ«rfundimtar i protokollit Ă«shtĂ« i mundur vetĂ«m pas kryerjes sĂ« testeve masive qĂ« marrin parasysh tĂ« gjitha aspektet nga setup-i deri te simulimi i dĂ«shtimeve, prandaj Ă«shtĂ« e vĂ«shtirĂ« qĂ« tĂ« gjeni receta tĂ« gatshme nĂ« whitepaper-at e ekipeve dhe nĂ« artikuj, dhe ne pĂ«r njĂ« vit apo dy tĂ« ardhshĂ«m sigurisht se nuk do tĂ« guxojmĂ« tĂ« shkruajmĂ« âbĂ«ni ashtu, ashtu do tĂ« jetĂ« e saktĂ«â.
PĂ«r momentin, pĂ«r PVRB-nĂ« tonĂ« nĂ« bllokchain-in nĂ« zhvillim , jemi ndalur nĂ« pĂ«rdorimin e nĂ«nshkrimeve BLS me prag, kemi nĂ« plan tĂ« implementojmĂ« PVRB nĂ« nivelin e konsensusit, pasi verifikimi nĂ« kontrata inteligjente me njĂ« nivel tĂ« pranueshĂ«m sigurie pĂ«r momentin nuk Ă«shtĂ« i mundur. MundĂ«sisht, do tĂ« pĂ«rdorim dy skema: fillimisht njĂ« ndarje sekrete tĂ« shtrenjtĂ« pĂ«r krijimin e njĂ« random_seed afatgjatĂ«, dhe mĂ« pas do ta pĂ«rdorim si bazĂ« pĂ«r gjenerimin me frekuencĂ« tĂ« lartĂ« tĂ« rastĂ«sishĂ«m duke pĂ«rdorur nĂ«nshkrime BLS me prag tĂ« determinuara, ndoshta do tĂ« kufizohemi vetĂ«m nĂ« njĂ« nga skemat. Nuk Ă«shtĂ« e mundur tĂ« thuhet paraprakisht se çfarĂ« do tĂ« jetĂ« protokolli, pĂ«r fat tĂ« keq, vetĂ«m ajo qĂ« na jep pozitivizĂ«m Ă«shtĂ« se si nĂ« shkencĂ«, nĂ« detyrat inxhinierike, njĂ« rezultat negativ Ă«shtĂ« gjithashtu njĂ« rezultat, dhe çdo pĂ«rpjekje e re pĂ«r tĂ« zgjidhur njĂ« problem Ă«shtĂ« njĂ« shkallĂ« tjetĂ«r pĂ«r kĂ«rkimet e tĂ« gjithĂ«ve qĂ« janĂ« tĂ« angazhuar me kĂ«tĂ« çështje. PĂ«r tĂ« siguruar kĂ«rkesat nga ana e biznesit, ne po zgjidhim njĂ« problem praktik specifik â sigurimin e aplikacioneve tĂ« lojrave me njĂ« burim tĂ« besueshĂ«m tĂ« entropisĂ«, prandaj na duhet tĂ« kushtojmĂ« gjithashtu vĂ«mendje vetĂ« bloçheinu, veçanĂ«risht çështjeve tĂ« pĂ«rfundimit tĂ« zinxhirit dhe qeverisjes sĂ« rrjetit.
Dhe ndonëse për momentin nuk shohim në blockchain një PVRB të provuar dhe të qëndrueshëm, i cili do të ishte përdorur për një kohë të mjaftueshme për t'u testuar nga aplikacione reale, auditime të shumta, ngarkesa dhe sigurisht, sulme reale, numri i mundësive të verifikimit konfirmon se një zgjidhje ekziston, dhe një nga këto algoritme në fund do të zgjidhë problematikën. Ne do të jemi të lumtur të ndajnë rezultatet dhe falënderojmë ekipet e tjera që po punojnë në këtë çështje për artikujt dhe kodin që lejojnë inxhinierët të mos bien dy herë në të njëjtat kurthe.
Prandaj, kur tĂ« takoni njĂ« programues qĂ« projekton njĂ« rastĂ«si tĂ« decentralizuar, jini tĂ« kujdesshĂ«m dhe tĂ« kujdesshĂ«m, ofroni ndihmĂ«n psikologjike nĂ«se Ă«shtĂ« e nevojshme đ
Burimi: habr.com
