Do, via teamo finis la alfa-version de via blokĉeno, kaj estas tempo lanĉi testreton kaj poste ĉefreton. Vi havas veran blokĉenon, kun sendependaj partoprenantoj, bonan ekonomian modelon, sekurecon, vi desegnis regadon kaj nun estas tempo provi ĉion ĉi en ago. En ideala kripta-anarkia mondo, vi metas la genezan blokon en la reton, la fina kodo de la nodo kaj la validigiloj mem lanĉas ĉion, altigas ĉiujn helpajn servojn, kaj ĉio okazas per si mem. Sed ĉi tio estas en fikcia mondo, sed en la reala mondo, la teamo devas prepari sufiĉe da helpprogramaro kaj diversaj manipuladoj por helpi validigilojn lanĉi stabilan reton. Jen pri kio ĉi tiu artikolo temas.
Lanĉi retojn bazitajn sur "pruvo-de-intereso" tipo-konsentoj, kie validigiloj estas determinitaj per la voĉoj de sistemaj tokenposedantoj, estas sufiĉe specifa evento, ĉar eĉ lanĉi tradiciajn, centre administritajn sistemojn kun dekoj kaj centoj da serviloj ne estas facila. tasko en si mem, kaj la blokĉeno devas esti komencita per penado lojalaj sed sendependaj partoprenantoj. Kaj, se en korporacio, post ekfunkciigo, administrantoj havas plenan aliron al ĉiuj maŝinoj, protokoloj, ĝenerala monitorado, tiam validigiloj ne permesos al iu ajn aliri siajn servilojn kaj, plej verŝajne, preferos konstrui sian infrastrukturon sendepende, ĉar ĝi kontrolas aliron. al la ĉefaj havaĵoj de la validisto - palisaj balotantoj. Estas ĉi tiu konduto kiu ebligas konstrui distribuitajn sekurajn retojn - la sendependeco de la uzataj nubaj provizantoj, virtualaj kaj "nudaj" serviloj, malsamaj operaciumoj, ĉio ĉi ebligas al vi fari atakojn sur tia reto ekstreme neefikaj - tro malsamaj. programaro estas uzata. Ekzemple, Ethereum uzas du ĉefajn nodajn efektivigojn, en Go kaj en Rust, kaj atako kiu estas efika por unu efektivigo ne funkcias por la alia.
Tial, ĉiuj procezoj por lanĉado kaj funkciigado de blokĉenoj devas esti organizitaj tiel, ke iu ajn validigilo, aŭ eĉ grupeto de validigiloj, povus iam ajn elĵeti siajn komputilojn tra la fenestro kaj foriri, dum nenio devas rompi kaj la ceteraj validigiloj devus. daŭre efike subteni la operacian reton kaj konekti novajn validigilojn. Kiam oni lanĉas reton, kiam unu validigilo estas en Eŭropo, la dua en Sudameriko, kaj la tria en Azio, estas sufiĉe malfacile atingi la kunordigan laboron de kelkaj dekoj da sendependaj grupoj kaj rezulte interesi ilin.
Validigiloj
Ni imagu la lanĉon de hipoteza moderna blokĉeno (la plej granda parto de tio, kio estas priskribita, taŭgas por blokĉenoj bazitaj sur iu ajn moderna familio de blokĉenoj: Ethereum, EOS, Polkadot, Cosmos kaj aliaj, kiuj provizas pruvan konsenton. La ĉefaj karakteroj de tiaj blokĉenoj estas validigteamoj , engaĝitaj pri instalo de siaj propraj sendependaj serviloj kiuj validas kaj produktas novajn blokojn, kaj ricevas rekompencojn provizitajn de la reto por tiuj, kiuj partoprenas en la konsento.Por lanĉi novajn retojn, kelkaj dekoj da validigiloj estas bezonataj (tiel multaj povas nun nun). pli-malpli efike atingas konsenton en sekundoj), do la projekto anoncas registriĝon, en kiu validigiloj dividas publikajn informojn pri si kun uzantoj, konvinkante ilin, ke ili liveros altkvalitan servon al la lanĉita reto.
Valido estas komerco, kiu ebligas al vi ege precize taksi la potencialan enspezon de la validisto, rapide translokigi potencon inter projektoj, kaj se la reto, kiun li elektis, sukcesas, la validigilo povas, kiel plenrajta partoprenanto en la DAO kaj respondeca persono, disvolvi la projekton, aŭ simple provizi bonegan teknikan servon por tute travidebla, honeste gajnita mono. Kiam vi kalkulas la rekompencon por validigiloj, projektoj provas konsideri la kostojn de validigiloj kaj fari la rekompencon por blokoj tia, ke ĉi tiu komerco estas enspeziga, sed samtempe ne ebligas validigilojn malaltigi la ekonomion inundante ilin per mono kaj senigante aliajn retajn uzantojn de ĝi.
La komerco de validigiloj postulas certigi altan misfunkciadon de servoj, kio signifas altan nivelon de trejnado por devopoj kaj programistoj kaj multekostaj komputikresursoj. Eĉ sen neceso elmini haŝojn en pruvo-de-laboraj retoj, blokĉena nodo estas granda servo, kiu okupas multe da memoro, konsumas multajn kalkulojn, validas, skribas al disko kaj sendas grandajn kvantojn da datumoj al la reto. . Por stoki transakciajn protokolojn kaj blokĉenojn por blokĉeno kun pluraj miloj da malgrandaj transakcioj en bloko, stokado de 50 Gb aŭ pli nun estas postulata, kaj por blokoj ĝi devas esti SSD. Ŝtata datumbazo de blokĉenoj kun subteno por inteligentaj kontraktoj jam povas superi 64Gb da RAM. Serviloj kun la postulataj trajtoj estas sufiĉe multekostaj; Ethereum aŭ EOS-nodo povas kosti de 100 ĝis 200 $/monato. Aldonu al tio la plialtigitajn salajrojn por la daŭra laboro de programistoj kaj devopoj, kiuj dum la lanĉperiodo solvas problemojn eĉ nokte, ĉar iuj validigiloj facile troviĝas en alia hemisfero. Tamen, en la ĝustaj momentoj, posedi validigilon povas alporti seriozan enspezon (en la kazo de EOS, ĝis $ 10 tage).
Valido estas nur unu el la novaj eblaj IT-roloj por entreprenistoj kaj kompanioj; ĉar programistoj elpensas pli kaj pli kompleksajn algoritmojn, kiuj rekompencas honestecon kaj punas fraŭdon kaj ŝtelon, aperas servoj, kiuj plenumas la funkciojn de publikigado de gravaj datumoj (orakoloj), plenumante superrigardon. (deponaĵo tranĉanta kaj punado trompantoj publikigante pruvon de trompo), disputsolvo servoj, asekuro kaj opcioj, eĉ rubokolektado estas eble granda merkato en inteligentaj kontraktosistemoj kie necesas pagi por datumstokado.
Problemoj de lanĉo de blokĉeno
La malfermo de la blokĉeno, kiu ebligis al komputiloj de iu ajn lando libere partopreni en la reto kaj la facileco konekti ajnan skriptfanon al la reto laŭ instrukcioj pri GitHub, ne ĉiam estas avantaĝo. La serĉado de nova ĵetono ofte devigas validantojn "mini novan moneron ĉe la komenco", kun la espero, ke la indico altiĝos kaj la ŝanco rapide forĵeti siajn enspezojn. Ankaŭ tio signifas, ke via validisto povas esti iu ajn, eĉ anonima persono, vi povas voĉdoni por li same kiel por aliaj validigiloj (tamen, estos malfacile por anonimulo kolekti voĉdonojn de koncernatoj por si, do ni' lasos la timigajn rakontojn pri anonimaj kriptaj moneroj al politikistoj). Tamen
La projektteamo havas taskon - iel eniri en sian reton tiujn, kiuj estonte kapablas certigi la stabilan funkciadon de nodoj, kompreni sekurecon, scipovas rapide solvi problemojn, kunlabori kun aliaj validigiloj kaj agi kune - la kvalito de tio tre afero plene dependas de ĉi tiuj kvalitoj signo en kiu retaj partoprenantoj investos sian tempon kaj rimedojn. Adekvataj fondintoj, taksante la riskojn, komprenas bone, ke lanĉante ĉi tiun grandecon programaro, vi certe devos renkonti erarojn en la kodo kaj agordo de nodoj, kaj ke la stabileco de la reto dependas de kiom bone programistoj kaj validigiloj kune solvos. tiaj problemoj.
La teamo pretas voĉdoni en la ĉefreto por iuj validigiloj, nur por scii kiuj, kiuj estas bonaj? La plej granda biletujo? Preskaŭ neniu havas ĝin nun. Surbaze de la Linkedin-profiloj de la teamo? Spertaj devopoj aŭ sekurecaj specialistoj ne donos al vi profilojn de Linkedin. Laŭ deklaroj en babilejo, afiŝoj kaj helpi aliajn dum la prepara fazo? Bona, sed subjektiva kaj malpreciza.
En tiaj kondiĉoj, unu afero restas - io, kio bone solvas ĉies problemojn - ludo, en kiu eblos elekti la plej bonajn validigilojn, sed la ĉefa afero estas provi la blokĉenon por forto kaj fari plenskalan batalteston de la. blokĉeno en kondiĉoj de aktiva uzo, ŝanĝoj en konsento, aspekto kaj korekto de eraroj. Ĉi tiu proceduro unue estis prezentita kiel ludo de la uloj de la projekto Cosmos, kaj ĉi tiu ideo estas sendube bonega maniero prepari la reton por la lanĉo de fidinda kaj tolerema ĉefreto.
Ludo de Validatoroj
Mi priskribos la ludon de validigiloj kiel ni desegnis ĝin por la blokĉeno DAO.Casino (DAOBet) bazita sur la EOS-forko, kiu nomiĝas Haya kaj havas similan regan mekanismon - validigiloj estas elektitaj per voĉdonado de iu ajn konto, en kiu parto de la bilanco uzata por voĉdoni por la validigilo estas frostigita. Ĉiu konto, kiu havas la ĉefan BET-ĵetonon sur sia saldo, povas voĉdoni por la elektita validigilo kun iu ajn parto de sia saldo. La voĉoj estas resumitaj kaj la ĉefaj validigiloj estas konstruitaj surbaze de la rezultoj. En malsamaj blokĉenoj ĉi tiu procezo estas organizita malsame, kaj kutime estas en ĉi tiu parto ke la nova blokĉeno diferencas de la gepatra, kaj mi devas diri, ke en nia kazo, EOS plene pravigas la "OS" en sia nomo, ni vere uzas EOS. kiel la baza operaciumo por deplojo de modifita versio de la blokĉeno por taskoj DAOBet.
Mi priskribos individuajn problemojn kaj kiel ili povas esti solvitaj en la ludo. Ni imagu reton en kiu via servilo povas esti malkaŝe atakata, kie por konservi la pozicion de validigilo vi devas senĉese interagi kun la reto, promociante vian validigilon kaj certigante ke ĝi produktas blokojn kaj ili estas liveritaj al aliaj validigiloj je tempo, alie la validigilo estos forĵetita el la listo.
Kiel elekti plej bonajn gajnintojn?
La ĉefa teknika postulo por la ludo estas, ke ĝiaj rezultoj estu publike kontroleblaj. Ĉi tio signifas, ke la rezultoj de la ludo: TOP-gajnintoj, devas esti formitaj strikte surbaze de datumoj, kiuj povas esti kontrolitaj de iu ajn partoprenanto. En centralizita sistemo, ni povus mezuri la "funkcitempon" de ĉiu validigilo kaj rekompenci tiujn, kiuj plej estis interretaj aŭ trapasis la maksimuman retan trafikon. Vi povas kolekti datumojn pri procesoro kaj memorŝarĝo kaj rekompenci tiujn, kiuj bone funkciis. Sed ĉiu tia kolekto de metrikoj signifas la ekziston de kolektocentro, kaj la nodoj estas ĉiuj sendependaj kaj povas konduti kiel ili volas kaj sendi ajnajn datumojn.
Sekve, la natura solvo estas, ke la gajnintoj estu determinitaj surbaze de datumoj de la blokĉeno, ĉar ĝi povas esti uzata por vidi, kiu validigilo produktis kiun blokon kaj kiajn transakciojn estis inkluditaj en ĝi. Ni nomis ĉi tiun nombron Validator Points (VP), kaj gajni ilin estas la ĉefa celo de validigiloj en la ludo. En nia kazo, la plej simpla, facile publike kontrolebla kaj efika metriko de la "utilo" de validigilo estas VP = nombro da blokoj produktitaj de la validigilo en antaŭfiksita tempoperiodo.
Ĉi tiu simpla elekto ŝuldiĝas al la fakto, ke regado en EOS jam provizas multajn emerĝajn problemojn, ĉar EOS estas la heredonto de tri generacioj de efektive laborantaj blokĉenoj kun ampleksa sperto en kompleksa retaj administrado, kaj preskaŭ ajnaj validaj problemoj kun la reto, procesoro, disko kondukas al nur unu problemo - li subskribas malpli da blokoj, ricevas malpli da pago por la laboro, kio denove kondukas nin simple al la nombro da subskribitaj blokoj - por EOS ĉi tio estas bonega kaj simpla opcio.
Por aliaj blokĉenoj, la maniero kiel Validator Points estas kalkulitaj povas malsami, ekzemple, por pBFT-bazitaj interkonsentoj (Tendermint/Cosmos, Aura konsento de Parity Substrate), kie ĉiu bloko devas esti subskribita de multoblaj validigiloj, estas senco nombri individuan validigilon. subskriboj prefere ol blokoj.Povas havi sencon konsideri nekompletajn konsentajn rondojn, kiuj malŝparas la rimedojn de aliaj validigiloj, ĝenerale tio tre dependas de la tipo de konsento.
Kiel simuli realajn funkciajn kondiĉojn
La tasko de la fondintoj estas testi validigilojn sub kondiĉoj proksimaj al realeco, sen havi ajnan centralizitan kontrolon. Ĉi tiu problemo povas esti solvita uzante krankontrakton, kiu distribuas egalajn kvantojn de la ĉefa ĵetono al validigiloj kaj ĉiuj aliaj. Por ricevi ĵetonojn sur via saldo, vi devas krei transakcion kaj certigi, ke la reto inkluzivas ĝin en la bloko. Tiel, por venki, validisto devas konstante replenigi sian ekvilibron per novaj ĵetonoj kaj voĉdoni por si mem, promociante sin al la supro. Ĉi tiu agado kreas konstantan ŝarĝon en la reto, kaj la parametroj povas esti elektitaj tiel ke la fluo de petoj estas sufiĉe severa por plena reto-testo. Sekve, planu la kranon kontrakton anticipe kiel grava ilo por lanĉi la reton kaj komencu elekti ĝiajn parametrojn anticipe.
Peti ĵetonojn de krano kaj validigi voĉojn ankoraŭ ne plene imitas la funkciadon de eksplodilo, precipe en ekstreme ŝarĝitaj reĝimoj. Sekve, la blokĉena teamo ankoraŭ devos skribi pliajn komparnormojn laŭ unu maniero aŭ alia por ŝarĝi la reton. Specialan rolon en tio ludas speciale kreitaj inteligentaj kontraktoj, kiuj permesas testi apartan subsistemon. Por testi stokadon, la kontrakto stokas hazardajn datumojn en la blokĉeno, kaj por testi retajn rimedojn, la testkontrakto postulas grandan kvanton da enigo-datumoj, tiel ŝveligante la volumon de transakcioj - lanĉante fluon de tiaj transakcioj je arbitraj punktoj en la tempo, la teamo samtempe testas la stabilecon de la kodo kaj la forton de la validigiloj.
Aparta afero estas ĝisdatigi la kodon de nodoj kaj konduki malmolajn forkojn. Estas postulate, ke okaze de cimo, vundebleco aŭ koluzioj de malicaj validigiloj, validigiloj havu agadplanon, kiu jam estis ellaborita en la ludo de la validigiloj. Ĉi tie vi povas elpensi skemojn por akiri VP por rapide apliki malmolan forkon, ekzemple, per monpuno de ĉiuj validigiloj, kiuj ankoraŭ ne lanĉis novan version de la noda kodo, sed ĉi tio malfacilas efektivigi kaj malfaciligas la kalkulon. Vi povas simuli la situacion de kriz-uzo de malmola forko artefarite "rompante" la blokĉenon sur difinita bloko. Blokoproduktado ĉesas, kaj finfine la gajnantoj estos tiuj, kiuj unue ensaltos kaj komencas subskribi blokojn, do VP bazita sur la nombro da subskribitaj blokoj taŭgas ĉi tie.
Kiel informi partoprenantojn pri la reto-stato kaj ripari erarojn
Malgraŭ la malfido inter validigiloj, ĝustatempa ricevo de ĝisdataj informoj pri la stato de la reto estas utila por ĉiuj por fari decidojn pli rapide, do la projektteamo altigas servon por kolekti kaj bildigi multajn metrikojn de validigaj serviloj, kiu ebligas al vi vidi la situacion samtempe por la tuta reto, permesante al vi rapide determini kio okazas. Ankaŭ, estas utile kaj por la validigiloj kaj la projekto, ke la projektteamo rapide korektas la trovitajn erarojn, do krom kolekti metrikojn, ĝi havas sencon tuj komenci kolekti protokolojn kaj erarajn datumojn de maŝinoj de validigiloj sur maŝino alirebla por blokĉeno. programistoj. Ĉi tie, ne estas utile por iu ajn distordi informojn, do ĉi tiuj servoj estas evoluigitaj de la projektteamo kaj povas esti fidindaj. Ĝi havas sencon kolekti sistemajn metrikojn de validigiloj, kaj, kompreneble, la plej gravaj metrikoj de la blokĉeno mem - por DAOBet - estas la finfina tempo kaj la malfruo de la lasta finita bloko. Dank'al ĉi tio, la teamo vidas pliiĝon en memorkonsumo sur nodoj dum funkciado de la komparnormo, problemoj kun individuaj validigiloj.
Gravaj punktoj por fari validigludon
Kiel rezultas, se vi volas oficiale permesi validigilojn ataki la maŝinojn de unu la alian (neoficiale ili povas fari tion ĉiuokaze), vi devas aparte formuli tion laŭleĝe kiel sekurecan provon, ĉar laŭ la leĝoj de iuj landoj DDoS aŭ retaj atakoj povas esti. punita. Alia grava afero estas kiel rekompenci validigilojn. Naturaj premioj estas projektaj ĵetonoj, kiuj estos translokigitaj al la ĉefreto, sed amasa distribuado de ĵetonoj al iu ajn, kiu povis lanĉi nodon, ankaŭ ne estas la plej bona elekto. Plej verŝajne vi devos ekvilibrigi inter du ekstremaj elektoj:
Distribuu la tutan premion laŭ la VP gajnita
ĝi estas tre demokrata kaj permesas al ĉiuj, kiuj investis tempon kaj rimedojn en la validigilon, gajni monon
sed altiras hazardajn homojn al la ludo sen preta infrastrukturo
Distribuu la plej-N-premion al validistoj bazitaj sur la rezultoj de la ludo
La gajnintoj plej verŝajne estos la validistoj, kiuj plej konsekvence daŭris dum la ludo kaj estas tre strikte deciditaj venki.
iuj validigiloj ne volos partopreni, malalte taksante siajn ŝancojn gajni, precipe se la partoprenantoj inkluzivas respektindajn validulojn.
Kiun opcion elekti dependas de vi
Estas unu plia punkto - tute ne estas fakto, ke dekoj da validigiloj rapidos partopreni la ludon laŭ via voko, kaj el tiuj, kiuj decidas provi, ne ĉiuj eĉ instalos kaj lanĉos la nodon - kutime, en ĉi tiu etapo, projektoj havas sufiĉe malabundan dokumentadon, eraroj estas renkontitaj, kaj programistoj laborantaj sub tempopremo ne respondas demandojn tre rapide. Tial, antaŭ lanĉi la ludon, ankaŭ necesas provizi agojn se la bezonata nombro da validigiloj ne estas atingita. En ĉi tiu kazo, ĉe la komenco de la ludo, la mankantaj validigiloj estas lanĉitaj de la projektteamo, partoprenas konsenton, sed ne povas esti gajnantoj.
konkludo
Konklude, mi provis kompili el ĉi-supraj liston de tio, kio necesas elpensi, fari kaj lanĉi por efike fari validigilon.
Kion vi devas fari por ruli veran validigilon:
disvolvu vian propran blokĉenon :)
- fari kaj altigi retan interfacon kaj provizi CLI por voĉdoni por validigiloj
- certigu, ke metrikoj de kuranta validigilo-nodo povas esti senditaj al centralizita servo (ekzemple Prometheus)
- altigu kalkulservilon (Prometheus + Grafana) por la validiga ludo
- eltrovu kiel Validator-Poentoj (VP) estos kalkulitaj
- disvolvi publikan skripton, kiu kalkulas validigilon VP surbaze de datumoj de la blokĉeno
- evoluigi retinterfacon por montri la ĉefajn validigilojn, kaj la ludstatuson de la validigiloj (kiom da tempo restas ĝis la fino, kiu havas kiom da VP, ktp.)
- disvolvu kaj aŭtomatigu la lanĉon de arbitra nombro da viaj propraj nodoj, projektu la procezon de konekto de validigiloj al la ludo (kiam kaj kiel malkonekti viajn nodojn, sendi kaj forigi voĉojn por ili)
- kalkulu kiom da ĵetonoj devas esti eldonitaj kaj disvolvu krankontrakton
- faru komparnorman skripton (ĵeton-translokigoj, amasa stokadouzo, amasa reto-uzo)
- kunvenigu ĉiujn partoprenantojn en unu babilejo por rapida komunikado
- lanĉi la blokĉenon iom pli frue ol la komenco de la ludo
- atendu la startblokon, komencu la ludon
- testi la reton kun pluraj specoj de transakcioj
- etendi malmolan forkon
- ŝanĝi la liston de validigiloj
- ripetu paŝojn 13,14,15, XNUMX, XNUMX en malsamaj ordoj, konservante retan stabilecon
- atendu la finan blokon, fini la ludon, kalkulu VP
Oni devas diri, ke la ludo de validigiloj estas nova rakonto, kaj ĝi estis efektivigita nur kelkajn fojojn, do vi ne devas preni ĉi tiun tekston kiel pretan gvidilon. Ne ekzistas analogoj en la moderna IT-komerco - imagu, ke bankoj, antaŭ ol lanĉi pagsistemon, konkuras unu kun la alia por vidi kiu estos la plej bona por fari klientajn transakciojn. Tradiciaj aliroj verŝajne ne helpos vin krei grandajn malcentralizitajn retojn, do regi novajn komercajn modelojn, ruli viajn ludojn, identigi la indajn, rekompenci ilin kaj konservi viajn distribuitajn sistemojn funkcii rapide kaj stabile.
fonto: www.habr.com