­č窭čç░ Pochopenie ├║lohy cel├ęho uzla v sie┼ąovom konsenze

Pochopenie ├║lohy cel├ęho uzla v sie┼ąovom konsenze

Uzly v distribuovanej sieti nemaj├║ rovnak├║ poz├şciu v sie┼ąovom konsenze. Uzly v├Żrobcov blokov maj├║ silnej┼íiu poz├şciu ako be┼żn├ę uzly pln├Żch u┼ż├şvate─żov. V tomto ─Źl├ínku budeme hovori┼ą o ├║lohe pln├Żch uzlov v kontexte produkcie blokov a riadenia. Pozrieme sa aj na moderniz├íciu siete prostredn├şctvom hard-fork kombin├ítora.

Uzol vs. drah├Ż zdroj

Decentraliz├íciu m├┤┼żeme sk├║ma┼ą z h─żadiska produkcie blokov a spr├ívy. Obe si vy┼żaduj├║ uzly a drah├Ż zdroj. V prvom rade je potrebn├ę pochopi┼ą ich v├Żznam v kontexte decentraliz├ície.

Pod drah├Żm zdrojom rozumieme mincu ADA v pr├şpade Cardano alebo hash rate v pr├şpade Bitcoinu.

Na v├Żrobu blokov s├║ potrebn├ę len uzly v├Żrobcov blokov (pooly) a drah├Ż zdroj. T├║to ─Źinnos┼ą mo┼żno prakticky vykon├íva┼ą bez podpory in├Żch (bloky neprodukuj├║cich) plnohodnotn├Żch uzlov.

Na obr├ízku ni┼ż┼íie m├┤┼żete vidie┼ą pln├ę uzly a pooly. Drah├Ż zdroj je delegovan├Ż na pooly, tak┼że maj├║ v sieti silnej┼íie postavenie. Pooly m├┤┼żu produkova┼ą bloky, zatia─ż ─Źo pln├ę uzly nie. Nez├íle┼ż├ş na tom, ─Źi s├║ mince ADA alebo r├Żchlos┼ą ha┼íovania delegovan├ę na pooly.

─Żudia m├┤┼żu vlastni┼ą drah├Ż zdroj a nejak├Żm sp├┤sobom ho delegova┼ą na uzly v├Żrobcov blokov. Mince ADA m├┤┼żu by┼ą delegovan├ę z ─żahkej pe┼ła┼żenky do ak├ęhoko─żvek poolu Cardano. Delegovanie spo─Ź├şva v odoslan├ş transakcie s certifik├ítom, ktor├Ż umo┼żn├ş zahrn├║┼ą mince ADA do celkov├ęho podielu zvolen├ęho poolu. Pool, t. j. uzol producenta blokov, z├şskava delegovan├şm silnej┼íie postavenie v sieti, preto┼że m├┤┼że produkova┼ą viac blokov. O to─żko blokov viac, o ko─żko sa zv├Ż┼íil jeho celkov├Ż podiel. ├Üplne rovnak├Żm sp├┤sobom m├┤┼żu ostatn├ş tvorcovia blokov delegova┼ą mince ADA do in├Żch poolov.

Be┼żn├ş pou┼ż├şvatelia m├┤┼żu spusti┼ą plnohodnotn├Ż uzol (pe┼ła┼żenku Daedalus) a posla┼ą z neho delega─Źn├Ż certifik├ít. Sp├┤sob delegovania je v┼íak v kontexte decentraliz├ície irelevantn├Ż (za predpokladu, ┼że stakeri vlastnia s├║kromn├ę k─ż├║─Źe k minciam ADA).

V pr├şpade Bitcoinu je situ├ícia ve─żmi podobn├í. ┼Ąa┼żiari deleguj├║ r├Żchlos┼ą hashovania na vybran├Ż pool prostredn├şctvom hardv├ęru ASIC.

V┼íimnite si, ┼że ani stakeri, ani ban├şci nemusia prev├ídzkova┼ą svoje vlastn├ę plnohodnotn├ę uzly a st├íle rozhoduj├║ o tom, ktor├Ż pool bude produkova┼ą bloky s ich delegovanou rozhodovacou pr├ívomocou.

Riadenie je tie┼ż z├ívisl├ę od drah├ęho zdroja na hlasovanie o aktualiz├íci├ích siete, distrib├║ciu minc├ş z projektovej pokladnice alebo in├ę veci. Hlasovanie prostredn├şctvom uzlov nie je mo┼żn├ę kv├┤li hrozbe Sybilov├Żch ├║tokov.

Sybilov ├║tok je typ ├║toku na sie┼ą, pri ktorom ┼íkodliv├Ż akt├ęr vytvor├ş viacero falo┼ín├Żch ident├şt alebo uzlov, aby z├şskal v├Ą─Ź┼í├ş vplyv alebo kontrolu nad sie┼ąou.

Na obr├ízku ni┼ż┼íie m├┤┼żete vidie┼ą 4 pou┼ż├şvate─żov, ktor├ş prev├ídzkuj├║ pln├ę uzly, a ├║to─Źn├şka (Sybil), ktor├Ż pre seba vytvoril dvojn├ísobn├Ż po─Źet uzlov.

Je potrebn├ę hlasova┼ą prostredn├şctvom minc├ş (alebo hash rate) a nie prostredn├şctvom uzlov, preto┼że hlasovanie prostredn├şctvom uzlov je zranite─żn├ę. Ak by bolo hlasovanie cez uzly povolen├ę, ├║to─Źn├şk by mohol vytvori┼ą mnoho falo┼ín├Żch uzlov (do─Źasne prideli┼ą ve─żk├Ż po─Źet IP adries) a hlasova┼ą za svoje z├íujmy alebo preferencie bez toho, aby musel do siete investova┼ą ak├ęko─żvek zdroje alebo podiel. T├Żm by z├şskal nespravodliv├║ v├Żhodu oproti ─Źestn├Żm uzlom a ohrozil by spravodlivos┼ą a legit├şmnos┼ą hlasovacieho procesu.

Na druhej strane hlasovanie prostredn├şctvom drah├Żch zdrojov vy┼żaduje, aby ├║─Źastn├şci preuk├ízali, ┼że do siete investovali ur─Źit├ę n├íkladn├ę zdroje. To ├║to─Źn├şkovi s┼ąa┼żuje a predra┼żuje vytv├íranie falo┼ín├Żch uzlov alebo hlasov a zabezpe─Źuje, ┼że rozhodnutia siete m├┤┼żu ovplyv┼łova┼ą len t├ş, ktor├ş maj├║ na nej podiel.

Hlasovanie prostredn├şctvom minc├ş ADA alebo hash rate zos├║la─Ćuje motiv├íciu ├║─Źastn├şkov so z├íujmami siete, ke─Ć┼że profituj├║ z udr┼żiavania jej bezpe─Źnosti a stability.

V┼íimnite si, ┼że na hlasovanie nie je potrebn├ę spusti┼ą ani vlastn├Ż plnohodnotn├Ż uzol. Existuje v┼íak pr├şpad, ke─Ć pou┼ż├şvatelia m├┤┼żu hlasova┼ą prostredn├şctvom be┼żn├Żch pln├Żch uzlov.

Jedinou formou hlasovania, pri ktorej plnohodnotn├ę uzly zohr├ívaj├║ d├┤le┼żitej┼íiu (ale nie nevyhnutn├║) ├║lohu, je prechod na nov┼íiu alebo in├║ verziu klienta. Ak sa v sieti objavia dve nekompatibiln├ę verzie klienta, m├┤┼że d├┤js┼ą k roz┼ítiepeniu blockchainu. Forky blockchainu (a teda aj siete) s├║ nepr├şjemn├ę, preto┼że zni┼żuj├║ bezpe─Źnos┼ą a stabilitu siete, sp├┤sobuj├║ roztrie┼ítenos┼ą medzi pou┼ż├şvate─żmi, v├Żvoj├írmi a komunitou a m├┤┼żu vies┼ą k vzniku nov├Żch minc├ş (cash, classic at─Ć.).

V pr├şpade platforiem SC, ako s├║ Cardano alebo Ethereum, sa tokeny (stablecoins), NFT a aplik├ície m├┤┼żu teoreticky duplikova┼ą. K tejto t├ęme sa vr├ítime nesk├┤r a vysvetl├şme, pre─Źo sa to v sieti Cardano nem├┤┼że sta┼ą.

Je d├┤le┼żit├ę si uvedomi┼ą, ┼że aj v tomto pr├şpade je ├║loha drah├ęho zdroja absol├║tne k─ż├║─Źov├í. Blockchainy s├║ zabezpe─Źen├ę a decentralizovan├ę prostredn├şctvom drah├ęho (vz├ícneho) zdroja, nie prostredn├şctvom pln├Żch uzlov. Vlastn├şci zdroja rozhoduj├║ o tom, ktor├í sie┼ą bude bezpe─Źnej┼íia (a teoreticky aj decentralizovanej┼íia).

Odhadn├║┼ą v├Żsledok forku siete je ┼ąa┼żk├ę, preto┼że v ┼łom hr├í ├║lohu mnoho detailov. Z├ívis├ş od rozhodnutia t├Żch, ktor├ş vlastnia v├Ą─Ź┼íinu drah├Żch zdrojov (m├┤┼żu to by┼ą in┼ítit├║cie alebo spolo─Źnosti). Ak s├║ projektov├ę mince duplikovan├ę, obe strany m├┤┼żu prv├║ verziu preda┼ą a druh├║ k├║pi┼ą.

Hlasovanie prostredn├şctvom uzlov (aj v pr├şpade forku siete) m├í ─Ćal┼íiu ve─żk├║ nev├Żhodu, a to n├şzke kv├│rum. Pri v├Ą─Ź┼íine siet├ş ani 1 % pou┼ż├şvate─żov neprev├ídzkuje plnohodnotn├Ż uzol. V kombin├ícii s hrozbou Sybilov├Żch ├║tokov sa hlasovanie prostredn├şctvom pln├Żch uzlov jav├ş ako nemo┼żn├ę. K moderniz├ícii siete sa vr├ítime nesk├┤r.

├Üloha pln├Żch uzlov pri tvorbe blokov

Pokia─ż ide o produkciu blokov, be┼żn├Ż pln├Ż uzol (nie producent blokov) prij├şma len platn├ę bloky, ktor├ę dostane. V pr├şpade forku uplat┼łuje pravidl├í pre v├Żber re┼ąazca. Pln├Ż uzol nezohr├íva v├┤bec ┼żiadnu ├║lohu, pokia─ż ide o v├Żber transakci├ş, ktor├ę maj├║ by┼ą zahrnut├ę do bloku, ani nerozhoduje o tom, ktor├Ż re┼ąazec vyhr├í v pr├şpade forku blockchainu.

Ak s├║ napr├şklad transakcie cenzurovan├ę prev├ídzkovate─żom poolu, vlastn├şk pln├ęho uzla s t├Żm nem├┤┼że ni─Ź urobi┼ą, na rozdiel od vlastn├şka drah├ęho zdroja.

Uk├í┼żme si to na praktickom pr├şklade. Pozrite sa na nasleduj├║ci obr├ízok.

O tom, ak├ę transakcie bud├║ vo v┼íetk├Żch blokoch, rozhoduj├║ len uzly v├Żrobcov blokov. Po bloku 5 do┼ílo k forku. Pln├ę uzly s t├Żm nem├┤┼żu ni─Ź robi┼ą a pas├şvne prij├şmaj├║ bloky 6 aj 7. Op├Ą┼ą len uzly producentov blokov (a drah├Ż zdroj) rozhoduj├║, ktor├Ż re┼ąazec vyhr├í. N├íhodne vybran├Ż producent blokov prid├í blok 8.

V pr├şpade forku sa v┼íetky uzly (vr├ítane poolov) v sieti riadia rovnak├Żmi pravidlami t├Żkaj├║cimi sa akcept├ície blokov a v├Żberu re┼ąazca v pr├şpade forku.

V pr├şpade Cardano plat├ş pravidlo najdlh┼íieho re┼ąazca. Ak s├║ oba re┼ąazce rovnako dlh├ę, rozhoduje v├Żstup VRF v posledn├Żch blokoch. N├íhodne vybran├Ż pool, ktor├Ż sa stal l├şdrom slotu, by mal vybra┼ą re┼ąazec, ktor├Ż m├í ni┼ż┼íiu hodnotu v├Żstupu VRF.

V pr├şpade Bitcoinu si prev├ídzkovate─ż poolu vyber├í re┼ąazec pod─ża vlastn├ęho uv├í┼żenia. Neexistuje ┼żiadne explicitn├ę pravidlo okrem pravidla o najdlh┼íom re┼ąazci. Viac ako polovicu po─Źtu blokov ┼ąa┼żia 2 pooly. Existuje ur─Źit├í ┼íanca, ┼że v pr├şpade forku sa pooly m├┤┼żu rozhodn├║┼ą pripoji┼ą nov├Ż blok za svoj vlastn├Ż (predch├ídzaj├║ci) blok.

Pooly maj├║ v niektor├Żch pr├şpadoch pr├ívo vo─żby, ktor├ę pas├şvne pln├ę uzly nemaj├║. Uk├ízali sme si to na pr├şklade forku. V pr├şpade Cardano nemus├ş prev├ídzkovate─ż poolu re┼ípektova┼ą pravidl├í a m├┤┼że pripoji┼ą nov├Ż blok za blok 6 alebo 7 bez oh─żadu na pravidlo t├Żkaj├║ce sa men┼íieho v├Żstupu VRF. Zvy┼íok siete nevie (a nem├┤┼że dok├íza┼ą), ┼że pool mal k dispoz├şcii oba bloky, t. j. ┼że vedel o forku. Ako sme u┼ż povedali, v pr├şpade Bitcoinu ide o slobodn├║ vo─żbu.

Pln├ę uzly len pas├şvne monitoruj├║ sie┼ą a prij├şmaj├║ ka┼żd├Ż platn├Ż blok. Ak d├┤jde k forku, ─Źakaj├║, k├Żm ho pooly vyrie┼íia. Ak sa v├Żroba blokov z nejak├ęho d├┤vodu zastav├ş, pln├Ż uzol nem├┤┼że sieti nijako pom├┤c┼ą. Ak pooly produkuj├║ pr├ízdne bloky, pln├Ż uzol ich mus├ş prija┼ą (pr├ízdny blok je platn├Ż blok).

Ak sa pool nechov├í v s├║lade so z├íujmami siete, pln├Ż uzol nem├í pr├ívomoc potresta┼ą prev├ídzkovate─ża poolu. Produkciu blokov plne kontroluj├║ producenti blokov a drah├Żch zdrojov. Potresta┼ą prev├ídzkovate─ża poolu je mo┼żn├ę len prostredn├şctvom drah├ęho zdroja, ktor├Ż on s├ím nevlastn├ş a je mu len delegovan├Ż.

K forkom sa vr├ítime e┼íte raz, preto┼że m├┤┼żu nasta┼ą po─Źas aktualiz├ície siete.

V kontexte decentraliz├ície m├í zmysel prev├ídzkova┼ą vlastn├Ż plnohodnotn├Ż uzol, preto┼że overuje pr├ícu baz├ęnov. Pln├ę uzly a uzly v├Żrobcov blokov musia dodr┼żiava┼ą rovnak├ę pravidl├í. Ak by sa jeden producent blokov pok├║sil poru┼íi┼ą pravidl├í a napr├şklad by sa pok├║sil vlo┼żi┼ą do bloku neplatn├║ transakciu, v┼íetky ostatn├ę uzly by to okam┼żite zistili a blok by neprijali. To je d├┤le┼żit├ę najm├Ą v pr├şpade ostatn├Żch baz├ęnov, preto┼że tie by neplatn├Ż blok tie┼ż vyradili. V├Żrobcovia blokov sa navz├íjom monitoruj├║ a pln├ę uzly m├┤┼żu monitorova┼ą v┼íetk├Żch v├Żrobcov blokov.

Ak by be┼żn├Ż prev├ídzkovate─ż pln├ęho uzla zistil probl├ęm s produkciou blokov, ve─żmi pravdepodobne by nebol jedin├Ż v sieti. V┼íetky pln├ę uzly by zistili rovnak├Ż probl├ęm. ─Żudia by sa mohli verejne s┼ąa┼żova┼ą na probl├ęmov├ęho prev├ídzkovate─ża (prev├ídzkovate─żov) poolu v n├ídeji, ┼że deleg├íti drah├ęho zdroja oslabia jeho poz├şciu delegovan├şm na in├Ż pool.

Nezab├║dajme, ┼że pln├ę uzly v sieti Cardano prev├ídzkuj├║ najm├Ą stakeri, tak┼że by pri nespr├ívnom spr├ívan├ş prev├ídzkovate─ża poolu okam┼żite delegovali mince ADA inde. To je v porovnan├ş s Bitcoinom v├Żhoda, preto┼że v sieti Bitcoin nie je be┼żn├ę, aby prev├ídzkovatelia pln├Żch uzlov prev├ídzkovali aj hardv├ęr ASIC.

Aktualizácia siete Cardano

Hard fork je typ zmeny protokolu, ktor├Ż zav├ídza nov├ę pravidl├í alebo funkcie, ktor├ę nie s├║ kompatibiln├ę s predch├ídzaj├║cou verziou. Hard fork zvy─Źajne vy┼żaduje, aby v┼íetky uzly v sieti pre┼íli na nov├║ verziu, inak zostan├║ v samostatnom re┼ąazci. Hard fork tie┼ż vytv├íra riziko rozdelenia ponuky minc├ş a pou┼ż├şvate─żskej z├íkladne, ako aj sp├┤sobuje zm├Ątok a neistotu medzi ├║─Źastn├şkmi siete.

Aktualiz├ícia je v sieti Cardano jednoduch├í a bezprobl├ęmov├í v─Ćaka jedine─Źn├ęmu n├ístroju naz├Żvan├ęmu hard-fork combinator.

Hard-fork combinator pou┼ż├şva sie┼ą Cardano na spojenie viacer├Żch hard forkov do jednej aktualiz├ície bez toho, aby do┼ílo k naru┼íeniu alebo zdvojeniu re┼ąazca a minc├ş.

Hard-fork combinator funguje tak, ┼że pou┼ż├şva ┼ípeci├ílne pravidlo ├║─Źtovnej knihy, ktor├ę dok├í┼że spoji┼ą viacero protokolov do jedn├ęho syst├ęmu a prep├şna┼ą medzi nimi vo vopred definovan├Żch ─Źasov├Żch bodoch. N├ístroj z├írove┼ł zachov├íva hist├│riu a kontinuitu blockchainu, ako aj platnos┼ą a jedine─Źnos┼ą minc├ş. Umo┼ż┼łuje spolo─Źnosti Cardano implementova┼ą nov├ę funkcie a vylep┼íenia bez toho, aby to ovplyvnilo be┼żn├║ prev├ídzku siete alebo vytvorilo ak├ęko─żvek vidlice ─Źi roz┼ítiepenia.

Na obr├ízku ni┼ż┼íie m├┤┼żete vidie┼ą, ┼że po bloku 4 do┼ílo k tvrd├ęmu rozvetveniu siete. Nov├ę pravidl├í siete platia od bloku 5 (zelen├Ż re┼ąazec). V tomto pr├şpade nie je hard fork ├║plne presn├Ż n├ízov, preto┼że v skuto─Źnosti k ┼żiadnemu rozvetveniu blockchainu nedo┼ílo. Na v├Ą─Ź┼íine uzlov nebude ┼żiadny osirel├Ż blok, len s├║visl├Ż re┼ąazec blokov.

Udalos┼ą hard fork combinator iniciuj├║ v├Żvoj├íri Cardano, ktor├ş rozhoduj├║ o tom, kedy a ako implementova┼ą nov├║ verziu protokolu (klienta), ktor├í zav├ídza do siete nov├ę funkcie alebo vylep┼íenia. Na pr├şpravu na udalos┼ą hard fork combinator musia prev├ídzkovatelia poolov nain┼ítalova┼ą nov├║ verziu klienta, ktor├í podporuje nov├║ verziu protokolu. Nov├Ż klient sa automaticky prepne na nov├║ verziu protokolu vo vopred definovanom okamihu bez toho, aby si vy┼żadoval ak├Żko─żvek manu├ílny z├ísah alebo koordin├íciu.

Prev├ídzkovatelia poolov sa m├┤┼żu slobodne rozhodn├║┼ą, ─Źi nov├║ verziu protokolu nain┼ítaluj├║ alebo nie. Ide o d├┤le┼żit├║ s├║─Źas┼ą spr├ívy. Udalos┼ą hard fork kombin├ítora nie je mo┼żn├ę spusti┼ą, ak nie je signalizovan├í dostato─Źn├í podpora.

V┼íimnite si, ak├║ ├║lohu v tom op├Ą┼ą zohr├íva drah├Ż zdroj, t. j. minca ADA. Stakeri m├┤┼żu skontrolova┼ą, ak├║ verziu protokolu maj├║ prev├ídzkovatelia poolu nain┼ítalovan├║. Ak sa niektor├ş z prev├ídzkovate─żov poolu rozhodn├║ nepodporova┼ą prechod na nov├║ verziu protokolu a verejne to ozn├ímia, je na dr┼żite─żoch ADA, ─Źi bud├║ t├Żchto prev├ídzkovate─żov poolu podporova┼ą prostredn├şctvom delegovania alebo ich opustia a deleguj├║ inde.

Ak d├┤jde k aktualiz├ícii siete, musia by┼ą samozrejme aktualizovan├ę aj pe┼ła┼żenky s pln├Żmi uzlami (pe┼ła┼żenka Daedalus). V┼íimnite si, ┼że pokia─ż ide o hlasovanie o zmene, pln├ę uzly op├Ą┼ą nezohrali takmer ┼żiadnu ├║lohu. Ak by pou┼ż├şvatelia boli proti zmene a zostali by na star┼íej verzii uzla (pe┼ła┼żenky), ich uzol by nemohol prij├şma┼ą nov├ę bloky.

Hard-fork kombin├ítor je jednou z inov├íci├ş, ktor├ę robia z Cardana flexibiln├║ a prisp├┤sobiv├║ blockchainov├║ platformu, ktor├í sa m├┤┼że ─Źasom vyv├şja┼ą a r├ís┼ą. Okrem toho d├íva rozhodovaciu pr├ívomoc do r├║k dr┼żite─żov ADA. Bez ich podpory a koordin├ície s prev├ídzkovate─żmi poolov nie je mo┼żn├ę inicializova┼ą udalos┼ą hard fork kombin├ítora.

Cardano bude z h─żadiska riadenia e┼íte decentralizovanej┼íie, ke─Ć bude inicializ├ícia hard fork combinator eventu v ruk├ích komunity. V tomto ┼ít├ídiu v┼íak t├şm nem├┤┼że presadzova┼ą zmeny pod─ża vlastnej v├┤le, preto┼że protokol riadia nez├ívisl├ę subjekty, nad ktor├Żmi nikto nem├í kontrolu.

Aktualizácia siete Bitcoin

V pr├şpade Bitcoinu je to v princ├şpe ve─żmi podobn├ę, a predsa odli┼ín├ę.

Na ├║─Źas┼ą v hard forku musia uzly upgradova┼ą na nov├║ verziu klienta, ktor├í podporuje nov├ę pravidl├í. Nov├Ż klient sa automaticky prepne na nov├║ verziu protokolu vo vopred definovanom okamihu bez toho, aby si vy┼żadoval ak├Żko─żvek manu├ílny z├ísah alebo koordin├íciu. Uzly, ktor├ę nebud├║ aktualizovan├ę, zostan├║ na starej verzii protokolu a nebud├║ m├┤c┼ą komunikova┼ą s uzlami, ktor├ę boli aktualizovan├ę.

Na obr├ízku ni┼ż┼íie do┼ílo k hard forku po bloku 4. Modr├Ż re┼ąazec je udr┼żiavan├Ż p├┤vodnou verziou klienta. Zelen├Ż re┼ąazec udr┼żiava nov├í (aktualizovan├í) verzia klienta.

Hash rate a hlasovanie s├║ dva faktory, ktor├ę ovplyv┼łuj├║ v├Żsledok hard forku.

Ha┼íovacia r├Żchlos┼ą je miera ┼ąa┼żobn├ęho v├Żkonu, ktor├Ż sa venuje v├Żrobe nov├Żch blokov.

Hlasovanie je proces signaliz├ície podpory alebo preferencie ur─Źitej verzie protokolu zvy┼íku siete pomocou ┼ípecifick├ęho bitu v hlavi─Źke bloku. Tento bit nastavuj├║ prev├ídzkovatelia bitcoinov├ęho poolu. Bit indikuje podporu ur─Źitej verzie pod─ża miery hashovania, ktor├║ poskytuj├║ ban├şci. Prev├ídzkovatelia poolov m├┤┼żu zhroma┼ż─Ćova┼ą ├║daje od ban├şkov a pod─ża toho nastavi┼ą bit. Bit m├┤┼żu prev├ídzkovatelia poolu kedyko─żvek zmeni┼ą v z├ívislosti od svojho rozhodnutia alebo strat├ęgie.

K signalizácii dochádza pred hard forkom.

Hash rate aj hlasovanie m├┤┼żu indikova┼ą ├║rove┼ł konsenzu a akcept├ície hard forku medzi ban├şkmi, ktor├ş s├║ zodpovedn├ş za zabezpe─Źenie a valid├íciu siete.

Hash rate a hlasovanie nie s├║ pre hard fork z├ív├Ązn├ę ani rozhoduj├║ce, preto┼że neodr├í┼żaj├║ n├ízory alebo z├íujmy v┼íetk├Żch ├║─Źastn├şkov siete. V┼íimnite si, ┼że prev├ídzkovatelia pln├Żch uzlov nem├┤┼żu vyjadri┼ą svoj n├ízor t├Żkaj├║ci sa aktualiz├ície siete. M├┤┼żu len sledova┼ą signaliz├íciu ┼ąa┼żiarov a pod─ża toho sa rozhodn├║┼ą, ─Źi aktualizuj├║ svoj vlastn├Ż uzol.

O v├Żsledku hard forku najviac rozhoduj├║ ban├şci, teda hash rate, ke─Ć┼że je v z├íujme v├Ą─Ź┼íiny ├║─Źastn├şkov zosta┼ą pri bezpe─Źnej┼íej re┼ąazi. Samozrejme, je mo┼żn├ę zosta┼ą aj pri menej bezpe─Źnom re┼ąazci. V kone─Źnom d├┤sledku v┼íak hard fork z├ívis├ş od trhov├Żch s├şl a rozhodnut├ş pou┼ż├şvate─żov, ktor├ę ur─Źuj├║ jeho hodnotu a prijatie.

V pr├şpade Bitcoinu do┼ílo v minulosti k nieko─żk├Żm duplik├íci├ím minc├ş a roztrie┼íteniu komunity (spolu s v├Żvoj├írmi). Ak si ─Źas┼ą komunity ┼żel├í zmenu prostredn├şctvom hard forku, stane sa tak. Zvy┼íok ├║─Źastn├şkov sa bu─Ć pripoj├ş k novej verzii klienta, alebo zostane pri starej verzii.

Pou┼ż├şvate─żom aktivovan├Ż hard fork (UAHF) je ┼ípeci├ílny typ zmeny protokolu v Bitcoine, ktor├Ż roz┼íiruje alebo upravuje pravidl├í. UAHF aktivuj├║ pou┼ż├şvatelia, ktor├ş pou┼ż├şvaj├║ softv├ęr s nov├Żmi pravidlami, a nevy┼żaduje si podporu v├Ą─Ź┼íiny ┼ąa┼żobnej sily. UAHF m├┤┼że sp├┤sobi┼ą rozdelenie blockchainu na dve (alebo viac) vetvy, ktor├ę nie s├║ navz├íjom kompatibiln├ę. Uzly s nov├Żmi pravidlami bud├║ nasledova┼ą svoj vlastn├Ż re┼ąazec bez oh─żadu na ich podporu ┼ąa┼żby.

UAHF je sp├┤sob, ako umo┼żni┼ą r├┤znym skupin├ím pou┼ż├şvate─żov Bitcoinu, ktor├ş maj├║ odli┼ín├ę n├ízory alebo v├şzie, aby sa dobrovo─żne oddelili od p├┤vodn├ęho re┼ąazca a vytvorili vlastn├║ verziu kryptomeny. Prev├ídzkovatelia plnohodnotn├Żch uzlov v┼íak nemusia ma┼ą z├íruku, ┼że sie┼ą bude dostato─Źne zabezpe─Źen├í ban├şkmi.

UAHF sa mi jav├ş ako ur─Źit├í forma n├ítlaku, ke─Ć prev├ídzkovatelia pln├Żch uzlov (pou┼ż├şvatelia) m├┤┼żu ignorova┼ą ban├şkov a naopak, ban├şci m├┤┼żu ignorova┼ą pou┼ż├şvate─żov.

Nie som si ist├Ż, ─Źi UAHF bude v bud├║cnosti relevantnou formou hlasovania. Ako bolo spomenut├ę vy┼í┼íie, len ve─żmi m├ílo ─żud├ş prev├ídzkuje vlastn├ę pln├ę uzly, tak┼że je mal├í ┼íanca, ┼że sa k men┼íine pou┼ż├şvate─żov prid├í v├Ą─Ź┼íina ban├şkov. Pln├ę uzly prev├ídzkovan├ę burzami m├┤┼żu ma┼ą vy┼í┼íiu v├íhu ako u┼ż├şvate─żsk├ę uzly.

Dovol├şm si tvrdi┼ą, ┼że aj v pr├şpade Bitcoinu zohr├ívaj├║ full nodes zanedbate─żn├║ ├║lohu a o aktualiz├íci├ích rozhoduj├║ najm├Ą ban├şci. Je v z├íujme pou┼ż├şvate─żov zosta┼ą pri najbezpe─Źnej┼íej verzii, t. j. re┼ípektova┼ą rozhodnutie ┼ąa┼żiarov. Dr┼żitelia ve─żk├ęho po─Źtu minc├ş a pr├şpadne bohat├ę subjekty (in┼ítit├║cie, fondy at─Ć.) v┼íak zohr├ívaj├║ v├Żznamn├║ ├║lohu, preto┼że ich n├íkup alebo predaj minc├ş priamo ovplyv┼łuje odmeny ban├şkov.

Pre Bitcoin by bol nepr├şjemn├Ż fork, ktor├Ż by rozdelil komunitu, a t├Żm aj hash rate na pribli┼żne dve rovnak├ę ─Źasti, preto┼że by z├írove┼ł zn├ş┼żil bezpe─Źnos┼ą Bitcoinu A a Bitcoinu B na polovicu (aspo┼ł kr├ítkodobo). O tom, ktor├Ż re┼ąazec si ponech├í p├┤vodn├Ż n├ízov Bitcoinu, rozhoduje hash rate, t. j. pravidlo dlh┼íieho re┼ąazca.

├Üloha t├şmov

Po─Ćme si poveda┼ą nie─Źo viac o ├║lohe t├şmov. Vplyv t├şmov na protokoly je relat├şvne mal├Ż, pokia─ż ide o decentraliz├íciu, preto┼że verzie klientov, ktor├ę navrhuj├║, mus├ş sie┼ą akceptova┼ą.

V pr├şpade Cardano je sila t├şmu o nie─Źo vy┼í┼íia ako v pr├şpade Bitcoinu, preto┼że t├şm (3 zakladaj├║ce subjekty) inicializuje udalos┼ą hard-fork combinator. To m├í ur─Źit├ę v├Żhody aj nev├Żhody. V├Żhodou je, ┼że sie┼ą Cardano nemo┼żno rozdeli┼ą. V┼żdy bude existova┼ą len jedna sie┼ą Cardano a 45 000 000 000 minc├ş ADA. Nikdy nebude existova┼ą Cardano Classic alebo Cardano Cash. Na druhej strane m├í t├şm kontrolu nad t├Żm, ─Źo je Cardano a ak├ę aktualiz├ície bude nov├í verzia klienta obsahova┼ą. Bolo by mo┼żn├ę vytvori┼ą hard fork bez hard fork kombin├ítora? Mo┼żno.

V pr├şpade Bitcoinu m├┤┼że hard fork urobi┼ą ktoko─żvek a kedyko─żvek. Blockchain forky a duplik├ícia minc├ş s├║ s├║─Źas┼ąou spr├ívy. Probl├ęmom je presved─Źi┼ą komunitu, ban├şkov, v├Żvoj├írov a tie┼ż burzy, aby nov├Ż re┼ąazec podporovali. Mysl├şm si, ┼że to je obrovsk├í prek├í┼żka nielen v pr├şpade Bitcoinu, ale aj v pr├şpade Cardana. V├Żznam blockchainovej siete je v prvom rade o komunite a prijat├ş a a┼ż v druhom rade o technol├│gii. Bez v├Żraznej podpory komunity nem├í zmysel uva┼żova┼ą o hard forku.

T├şm vytvor├ş nov├║ verziu klienta a pon├║kne ju komunite (sieti). Dr┼żitelia drah├Żch zdrojov a trhov├ę sily rozhodn├║, ktor├Ż klient sa bude pou┼ż├şva┼ą. V pr├şpade Cardano mus├ş komunita aktualiz├íciu prija┼ą, inak k nej v├┤bec ned├┤jde. K forku siete Cardano nem├┤┼że d├┤js┼ą. V pr├şpade Bitcoinu s├║ forky s├║─Źas┼ąou spr├ívy.

Na obr├ízku ni┼ż┼íie m├┤┼żete vidie┼ą t├şm, ktor├Ż komunite pon├║kol nov├║ verziu klienta (zelen├í farba). V├Ą─Ź┼íina prev├ídzkovate─żov poolov nov├║ verziu prijala. Jeden prev├ídzkovate─ż zostal na starej verzii (modr├í).

T├şm m├┤┼że ma┼ą kontrolu nad konsenzom siete, ak si ponech├í drah├Ż zdroj. V pr├şpade projektov PoS to m├┤┼że by┼ą jednoduch┼íie, preto┼że t├şm si m├┤┼że ponecha┼ą zna─Źn├║ ─Źas┼ą minc├ş. V pr├şpade Cardana je v┼íak drviv├í v├Ą─Ź┼íina minc├ş v ruk├ích komunity, tak┼że tak├ęto riziko nehroz├ş. Nemysl├şm si, ┼że ─Źlenovia t├şmu Bitcoin Core kontroluj├║ v├Żznamn├║ ─Źas┼ą hash rate. Kontrolu nad ┼ąa┼żbou v┼íak z├şskavaj├║ spolo─Źnosti ako Digital Currency Group a ned├ívno Black Rock. Prostredn├şctvom hash rate m├┤┼żu ma┼ą kontrolu nad aktualiz├íciami siete, teda nad t├şmom.

Decentraliz├ícia je v skuto─Źnosti ve─żmi komplexn├í vec. Keby sa bolo mo┼żn├ę zaob├şs┼ą bez drah├ęho zdroja (ktor├Ż si m├┤┼żu k├║pi┼ą bohat├ş ─żudia) a spolieha┼ą sa len na uzly umo┼ż┼łuj├║ce peer-to-peer komunik├íciu medzi pou┼ż├şvate─żmi, bolo by to jednoduch┼íie. Bez sie┼ąov├ęho konsenzu v┼íak nie je mo┼żn├ę zabezpe─Źi┼ą napr├şklad ochranu pred dvojit├Żm m├ş┼łan├şm minc├ş alebo nemennos┼ą menovej politiky (digit├ílny nedostatok). Protokol sie┼ąov├ęho konsenzu je nevyhnutn├Ż a ├║─Źastn├şci musia ma┼ą vlastn├║ ko┼żu v hre, preto┼że in├í forma ochrany neexistuje.

Nezab├║dajte, ┼że bezpe─Źnos┼ą siete (a ochrana pred 51% ├║tokmi) je prim├írne ur─Źen├í trhovou hodnotou minc├ş. Decentraliz├ícia z├ívis├ş od distrib├║cie drah├ęho zdroja. V pr├şpade aktualiz├ície siete je d├┤le┼żit├ę zachova┼ą tieto vlastnosti na ─Źo najlep┼íej ├║rovni.

Pln├ę uzly nemaj├║ takmer ┼żiadny vplyv na bezpe─Źnos┼ą alebo decentraliz├íciu. Hoci pln├ę uzly m├┤┼żu teoreticky ovplyvni┼ą v├Żsledok hlasovania, nem├┤┼żu priamo poskytova┼ą d├┤le┼żit├ę vlastnosti siete. M├┤┼żu to dosiahnu┼ą len nepriamo prejaven├şm v├┤le t├Żch, ktor├ş prev├ídzkuj├║ pln├ę uzly. Z m├┤jho poh─żadu je ove─ża efekt├şvnej┼íie hlasova┼ą prostredn├şctvom drah├ęho zdroja.

Záver

Spustenie pln├ęho uzla je v├Żhodn├ę pre va┼íe s├║kromie a nez├ívislos┼ą od tretej strany. M├┤┼żete tie┼ż sledova┼ą pr├ícu v├Żrobcov blokov. Z h─żadiska konsenzu a spr├ívy siete je v┼íak najd├┤le┼żitej┼í├ş drah├Ż zdroj.

Sybilsk├ę ├║toky zabra┼łuj├║ mo┼żnosti hlasova┼ą alebo si vytvori┼ą ak├Żko─żvek n├ízor na situ├íciu na z├íklade po─Źtu pln├Żch uzlov a ich mo┼żnej signaliz├ície. Mince najv├Ą─Ź┼í├şch blockchainov vlastnia desiatky a┼ż stovky mili├│nov pou┼ż├şvate─żov, zatia─ż ─Źo pln├ę uzly obsluhuj├║ tis├şce a┼ż desa┼ątis├şce ─żud├ş. To je ve─żk├Ż rozdiel, tak┼że po─Źet uzlov m├í ve─żmi n├şzku v├Żpovedn├║ hodnotu, pokia─ż ide o n├ízor pou┼ż├şvate─żov. V├Żroba blokov je zalo┼żen├í na drah├Żch zdrojoch a m├í zmysel pou┼ż├şva┼ą rovnak├ę princ├şpy pre hlasovanie a aktualiz├ície.

Niekedy sa stret├ívam s n├ízorom, ┼że kvalitu decentraliz├ície siete ur─Źuje predov┼íetk├Żm po─Źet pln├Żch uzlov. D├║fam, ┼że je zrejm├ę, ┼że to tak nem├┤┼że by┼ą. Rozhoduj├║cim faktorom je predov┼íetk├Żm po─Źet v├Żrobcov blokov a po─Źet deleg├ítov. V druhom rade je potrebn├ę zaobera┼ą sa t├Żm, ako sa distribuuje drah├Ż zdroj a ko─żko ve─żr├Żb je v syst├ęme.


P├┤vodn├Ż ─Źl├ínok: