Tehát csapata befejezte a blokklánc alfa verzióját, és ideje elindítani a testnetet, majd a mainnetet. Valódi blokkláncod van, független résztvevőkkel, jó gazdasági modellel, biztonsággal, megtervezted a kormányzást, és itt az ideje, hogy mindezt gyakorlatban is kipróbáld. Egy ideális kripto-anarchikus világban felteszed a genezis blokkot a hálózatra, a csomópont végső kódja és maguk a validátorok elindítanak mindent, felveszik az összes kiegészítő szolgáltatást, és minden magától történik. De ez egy kitalált világban van, de a valós világban a csapatnak elég sok segédszoftvert és különféle manipulációkat kell előkészítenie, hogy segítse az érvényesítőket egy stabil hálózat létrehozásában. Ez a cikk erről szól.
A „proof-of-stake” típusú konszenzusokon alapuló hálózatok elindítása, ahol a validátorokat a rendszerjogkivonat-tulajdonosok szavazatai határozzák meg, meglehetősen sajátos esemény, mert a hagyományos, központilag menedzselt, több tíz és száz szerverrel rendelkező rendszerek elindítása sem egyszerű feladat. feladat önmagában, és a blokkláncot lojális, de független résztvevőkkel kell elindítani. És ha egy vállalatnál induláskor az adminisztrátorok teljes hozzáféréssel rendelkeznek az összes géphez, naplóhoz, általános felügyelethez, akkor a validátorok nem engedik meg senkinek, hogy hozzáférjen a szervereikhez, és valószínűleg inkább önállóan építik fel infrastruktúrájukat, mert az szabályozza a hozzáférést. az érvényesítő fő eszközeire - tét szavazók. Ez a viselkedés teszi lehetővé az elosztott biztonságos hálózatok kiépítését - a használt felhőszolgáltatók függetlensége, virtuális és „csupasz” szerverek, különböző operációs rendszerek, mindez lehetővé teszi, hogy egy ilyen hálózat elleni támadásokat rendkívül hatástalanná tegyük - túlságosan eltérő szoftvert használják. Például az Ethereum két fő csomópont-megvalósítást használ, a Go-ban és a Rust-ban, és az egyik megvalósításra hatékony támadás nem működik a másik esetében.
Ezért a blokkláncok indításának és működtetésének minden folyamatát úgy kell megszervezni, hogy bármely validátor, vagy akár egy kis csoport is bármikor kidobhassa számítógépét az ablakon és távozzon, miközben semmi sem törhet el, és a többi érvényesítő továbbra is hatékonyan támogassa a működési hálózatot és csatlakoztasson új érvényesítőket. Egy hálózat indításakor, amikor az egyik validátor Európában, a második Dél-Amerikában, a harmadik Ázsiában található, meglehetősen nehéz több tucat független csoport összehangolt munkáját megvalósítani, és ennek eredményeként érdekelni őket.
Validátorok
Képzeljünk el egy hipotetikus modern blokklánc elindítását (a leírtak nagy része bármilyen modern blokklánc-családra épülő blokkláncokra alkalmas: Ethereum, EOS, Polkadot, Cosmos és mások, amelyek bizonyítják a tét konszenzust. A főszereplők Az ilyen blokkláncok validátorcsapatok, amelyek saját független szervereik telepítésével foglalkoznak, amelyek validálnak és új blokkokat állítanak elő, és a hálózat által biztosított jutalmakat kapják azok számára, akik részt vesznek a konszenzusban. Új hálózatok elindításához több tucat validátorra van szükség (annyira most már többé-kevésbé hatékonyan konszenzusra jutnak másodpercek alatt), így a projekt regisztrációt hirdet, melynek során a validátorok nyilvános információkat osztanak meg magukról a felhasználókkal, meggyőzve őket arról, hogy az elindított hálózatot magas színvonalú szolgáltatással fogják ellátni.
A validáció egy olyan vállalkozás, amely lehetővé teszi a validátor lehetséges bevételeinek rendkívül pontos felmérését, a projektek közötti erő gyors átadását, és ha az általa választott hálózat sikeres, akkor a validátor a DAO teljes jogú résztvevőjeként és felelős személyként fejleszteni a projektet, vagy egyszerűen csak kiváló műszaki szolgáltatást nyújtani teljesen átlátható, becsületesen megkeresett pénzért. A validátorok díjának kiszámításakor a projektek igyekeznek figyelembe venni a validátorok költségeit, és a blokkok jutalmát úgy alakítani, hogy ez az üzlet nyereséges legyen, ugyanakkor nem engedik, hogy a validátorok leépítsék a gazdaságot azzal, hogy pénzzel árasztják el őket. megfosztva tőle a hálózat többi felhasználóját.
A validátorok üzletága megköveteli a szolgáltatások magas hibatűrésének biztosítását, ami magas szintű képzést jelent a devopsoknak és a fejlesztőknek, valamint drága számítási erőforrásokat. A blokklánc-csomópont még a munkaellenőrzési hálózatok kivonatolása nélkül is egy nagy szolgáltatás, amely sok memóriát foglal, sok számítást igényel, érvényesít, lemezre ír és nagy mennyiségű adatot küld a hálózatra. . Egy blokkban több ezer kis tranzakciót tartalmazó blokklánc tranzakciónaplóinak és blokkláncainak tárolásához mostantól 50 Gb-os vagy nagyobb tárhely szükséges, a blokkokhoz pedig SSD-nek kell lennie. Az intelligens szerződéseket támogató blokkláncok állami adatbázisa már meghaladhatja a 64 Gb RAM-ot. A szükséges jellemzőkkel rendelkező szerverek meglehetősen drágák, egy Ethereum vagy EOS csomópont havi 100-200 dollárba kerülhet. Ehhez jön még a fejlesztők és a devopok éjjel-nappali munkájáért megemelt bér, akik az indulási időszakban még éjszaka is megoldanak problémákat, hiszen egyes validátorok könnyen egy másik féltekén is elhelyezkedhetnek. A megfelelő pillanatokban azonban egy validátor csomópont birtoklása komoly bevételt hozhat (EOS esetén akár napi 10 000 dollár).
A validálás csak egy a vállalkozók és cégek új potenciális IT-szerepei közül, ahogy a programozók egyre kifinomultabb algoritmusokkal állnak elő, amelyek jutalmazzák az őszinteséget, büntetik a csalásokat és lopásokat, megjelennek a fontos adatok közzétételét (orákulumok), felügyeletet ellátó szolgáltatások. (betétlevágás és a csalók megbüntetése a megtévesztés bizonyítékának közzétételével), vitarendezési szolgáltatások, biztosítás és opciók, sőt a szemétszállítás is potenciálisan nagy piac az okosszerződéses rendszerekben, ahol fizetni kell az adattárolásért.
A blokklánc indításának problémái
A blokklánc nyitottsága, amely lehetővé tette, hogy bármely ország számítógépei szabadon részt vegyenek a hálózatban, és a GitHubon található utasítások szerint bármilyen script kiddy könnyen csatlakoztatható a hálózathoz, nem mindig előny. Az új token keresése gyakran arra kényszeríti az érvényesítőket, hogy „kezdetkor új érmét bányászjanak”, abban a reményben, hogy az árfolyam emelkedni fog, és lehetőség nyílik arra, hogy gyorsan eldobják bevételeiket. Ez azt is jelenti, hogy az érvényesítője bárki lehet, akár névtelen személy is, ugyanúgy szavazhat rá, mint a többi érvényesítőre (azonban egy névtelen személynek nehéz lesz összegyűjtenie magának az érintettek szavazatait, ezért mi” A névtelen kriptovalutákról szóló ijesztő meséket a politikusokra hagyjuk). Mindazonáltal
A projektcsapatnak az a feladata, hogy valamilyen módon bekerüljön a hálózatába azokat, akik a jövőben képesek biztosítani a csomópontok stabil működését, megértik a biztonságot, tudják, hogyan lehet gyorsan megoldani a problémákat, együttműködnek más validátorokkal és együtt cselekednek - ennek minősége nagyon sok minden függ ezektől a tulajdonságoktól, amelyekbe a hálózat résztvevői befektetik idejüket és erőforrásaikat. A megfelelő alapítók a kockázatok felmérésekor jól megértik, hogy ekkora szoftver indításakor mindenképpen a csomópontok kód- és konfigurációs hibáival kell találkozni, és a hálózat stabilitása attól függ, hogy a fejlesztők és a validátorok közösen mennyire oldják meg a megoldást. ilyen problémákat.
A csapat készen áll arra, hogy szavazzon a mainneten bármilyen validátorra, csak hogy tudja, melyik, melyik a jó? A legnagyobb portfólió? Ma már szinte senkinek sincs meg. A csapat Linkedin profilja alapján? A tapasztalt fejlesztők vagy biztonsági szakemberek nem adnak Önnek Linkedin-profilt. A chatben, posztokban és mások segítésében a felkészülési szakaszban tett kijelentések szerint? Jó, de szubjektív és pontatlan.
Ilyen körülmények között egy dolog marad - valami, ami mindenki problémáit jól megoldja - egy játék, amelyben lehetőség lesz kiválasztani a legjobb érvényesítőket, de a lényeg az, hogy teszteljük a blokkláncot az erő szempontjából, és teljes körű harci tesztet hajtsunk végre a blokklánc az aktív használat körülményei között, a konszenzus változásai, a hibák megjelenése és javítása . Ezt az eljárást először játékként mutatták be a Cosmos projekt srácai, és ez az ötlet kétségtelenül kiváló módja annak, hogy a hálózatot felkészítsék egy megbízható és hibatűrő főhálózat elindítására.
Game of Validators
A validátorok játékát úgy írom le, ahogyan azt az EOS fork-on alapuló DAO.Casino (DAOBet) blokklánchoz terveztük, ami Haya néven működik, és hasonló irányítási mechanizmussal rendelkezik – a validátorokat bármely fiókból szavazással választjuk ki, amelyen a az érvényesítő szavazására használt egyenleg be van fagyasztva. Bármely számla, amelynek egyenlegén a fő BET token van, szavazhat a kiválasztott érvényesítőre az egyenlegének bármely részével. A szavazatokat összesítik, és az eredmények alapján felépítik a legjobb érvényesítőket. A különböző blokkláncokban ez a folyamat másképp szerveződik, és általában ebben a részben tér el az új blokklánc a szülőtől, és azt kell mondanom, hogy esetünkben az EOS teljes mértékben igazolja az „OS”-t a nevében, valóban EOS-t használunk. mint az alap operációs rendszer a blokklánc módosított változatának telepítéséhez a DAOBet feladatokhoz.
Leírom az egyes problémákat és a játékon belüli megoldásukat. Képzeljünk el egy olyan hálózatot, amelyben nyíltan támadható a szervere, ahol az érvényesítő pozíciójának megőrzéséhez folyamatosan interakcióba kell lépnie a hálózattal, promotálni a validátorát, és gondoskodnia kell arról, hogy blokkokat állítson elő, és azokat időben kézbesítsék a többi érvényesítőnek, ellenkező esetben a validátor kikerül a listából.
Hogyan válasszuk ki a legjobb nyerteseket?
A játék fő technikai követelménye, hogy eredményei nyilvánosan ellenőrizhetők legyenek. Ez azt jelenti, hogy a játék eredményét: TOP nyertesek, szigorúan bármely résztvevő által ellenőrizhető adatok alapján kell kialakítani. Egy központosított rendszerben mérni tudtuk az egyes validátorok „üzemidejét”, és jutalmazni tudtuk azokat, akik a legtöbbet voltak online vagy a maximális hálózati forgalman haladtak át. Adatokat gyűjthet a processzor- és memóriaterhelésről, és jutalmazhatja azokat, akik jól dolgoztak. De minden ilyen mérőszám-gyűjtemény egy gyűjtőközpont létezését jelenti, és a csomópontok mind függetlenek, és tetszőlegesen viselkedhetnek, és bármilyen adatot küldhetnek.
Ezért a természetes megoldás az, hogy a nyerteseket a blokkláncból származó adatok alapján kell meghatározni, hiszen annak segítségével lehet megnézni, hogy melyik validátor melyik blokkot produkálta és milyen tranzakciók kerültek bele. Ezt a számot Validator Pontoknak (VP) hívtuk, és ezek megszerzése az érvényesítők fő célja a játékban. Esetünkben a validátor „hasznosságának” legegyszerűbb, nyilvánosan könnyen ellenőrizhető és hatékony mérőszáma a VP = az érvényesítő által egy adott időszakban előállított blokkok száma.
Ez az egyszerű választás annak a ténynek köszönhető, hogy az EOS irányítása már számos felmerülő problémát biztosít, mivel az EOS a ténylegesen működő blokkláncok három generációjának örököse, nagy tapasztalattal rendelkezik a komplex hálózatkezelésben, és szinte minden, a hálózattal, processzorral kapcsolatos validátori problémával, A lemez csak egyetlen problémát okoz - kevesebb blokkot ír alá, kevesebb fizetést kap a munkáért, ami megint csak az aláírt blokkok számához vezet - az EOS számára ez egy kiváló és egyszerű lehetőség.
Más blokkláncok esetében a Validator Pontok kiszámításának módja eltérhet, például a pBFT-alapú konszenzusok esetében (Tendermint/Cosmos, Aura consensus from Parity Substrate), ahol minden blokkot több validátornak kell aláírnia, ésszerű az egyedi validátort számolni. Az aláírások helyett a blokkok. Érdemes lehet figyelembe venni a hiányos konszenzusköröket, amelyek más validátorok erőforrásait pazarolják, általában ez nagymértékben függ a konszenzus típusától.
Hogyan lehet szimulálni a valós működési feltételeket
Az alapítók feladata a validátorok tesztelése a valósághoz közeli körülmények között, központi irányítás nélkül. Ez a probléma megoldható egy csaptelep szerződéssel, amely egyenlő mennyiségben osztja ki a fő tokent az érvényesítőknek és mindenki másnak. Ahhoz, hogy tokeneket kaphasson egyenlegén, létre kell hoznia egy tranzakciót, és biztosítania kell, hogy a hálózat tartalmazza azt a blokkban. Így ahhoz, hogy nyerjen, az érvényesítőnek folyamatosan új jelzőkkel kell feltöltenie az egyenlegét, és önmagára kell szavaznia, ezzel előléptetve magát a csúcsra. Ez a tevékenység állandó terhelést hoz létre a hálózaton, és a paramétereket úgy lehet kiválasztani, hogy a kérések áramlása elég erős legyen a teljes hálózati teszthez. Ezért tervezze meg előre a csaptelep szerződést, mint a hálózat elindításának fontos eszközét, és kezdje el előre kiválasztani a paramétereit.
A csapból tokenek kérése és a szavazatok érvényesítése még mindig nem emulálja teljes mértékben a robbanófej működését, különösen rendkívül terhelt módokban. Ezért a blokklánc-csapatnak ilyen vagy olyan módon további benchmarkokat kell írnia a hálózat betöltéséhez. Ebben kiemelt szerepet játszanak a speciálisan létrehozott intelligens szerződések, amelyek lehetővé teszik egy külön alrendszer tesztelését. A tárolás teszteléséhez a szerződés véletlenszerű adatokat tárol a blokkláncban, a hálózati erőforrások teszteléséhez pedig a tesztszerződés nagy mennyiségű bemeneti adatot igényel, ezáltal megnöveli a tranzakciók volumenét - az ilyen tranzakciók áramlásának elindításával tetszőleges időpontban, a csapat egyszerre teszteli a kód stabilitását és a validátorok erősségét.
Külön probléma a csomópontok kódjának frissítése és a kemény villák levezetése. Szükséges, hogy hiba, sebezhetőség vagy rosszindulatú érvényesítők összejátszása esetén az érvényesítőknek rendelkezzenek olyan cselekvési tervvel, amelyet már kidolgoztak az érvényesítők játékában. Itt sémákat találhat ki a VP felhalmozására egy kemény villa gyors alkalmazásához, például pénzbírsággal sújtja az összes érvényesítőt, aki még nem dobta ki a csomópontkód új verzióját, de ezt nehéz megvalósítani, és bonyolítja a számítást. Szimulálhatja a keményvilla vészhelyzeti használatának helyzetét, ha mesterségesen „megtöri” a blokkláncot egy adott blokkon. A blokkgyártás leáll, és a végén azok lesznek a nyertesek, akik először ugranak be, és elkezdik aláírni a blokkokat, így az aláírt blokkok száma alapján a VP jól illeszkedik ide.
A résztvevők tájékoztatása a hálózat állapotáról és a hibák kijavítása
A validátorok közötti bizalmatlanság ellenére a hálózat állapotával kapcsolatos naprakész információk időben történő megérkezése mindenki számára előnyös a gyorsabb döntéshozatal érdekében, ezért a projektcsapat olyan szolgáltatást hoz létre, amely számos mérőszámot összegyűjt és megjelenít a validátor szerverekről, amely lehetővé teszi a helyzet egyidejű megtekintését a teljes hálózaton, így gyorsan meghatározhatja, mi történik. Emellett mind a validátorok, mind a projekt számára előnyös, hogy a projektcsapat gyorsan kijavítja a talált hibákat, így a mérőszámok gyűjtése mellett érdemes azonnal elkezdeni a naplók és hibaadatok gyűjtését a validátorok gépeiről egy blokklánc számára elérhető gépen. fejlesztők. Itt senkinek sem előnyös az információk eltorzítása, ezért ezeket a szolgáltatásokat a projektcsapat fejleszti, és megbízhatóak. Értelmes a rendszermérők gyűjtése a validátoroktól, és természetesen magának a blokkláncnak a legfontosabb mérőszámai - a DAOBet esetében - a véglegesítés ideje és az utolsó véglegesített blokk késése. Ennek köszönhetően a csapat a benchmark futtatásakor a csomópontok memóriafogyasztásának növekedését látja, problémákat tapasztal az egyes érvényesítőkkel
Fontos tudnivalók az érvényesítő játék lebonyolításához
Mint kiderült, ha hivatalosan meg akarjuk engedni, hogy a validátorok támadhassák egymás gépeit (nem hivatalosan amúgy is megtehetik), akkor ezt külön jogilag biztonsági tesztelésként kell megfogalmazni, hiszen egyes országok törvényei szerint a DDoS vagy hálózati támadások is megtámadhatók. megbüntették. Egy másik fontos kérdés az érvényesítők jutalmazása. A természetes nyeremények projekt tokenek, amelyek átkerülnek a mainnetre, de a tokenek tömeges szétosztása azoknak, akik képesek voltak egy csomópontot elindítani, szintén nem a legjobb megoldás. Valószínűleg két szélsőséges lehetőség között kell egyensúlyoznia:
Oszd el a teljes nyereményalapot a megszerzett VP szerint
nagyon demokratikus, és mindenki pénzt kereshet, aki időt és erőforrást fektetett a validátor játékba
de véletlenszerű embereket vonz a játékba előkészített infrastruktúra nélkül
A játék eredményei alapján oszd szét a top-N nyereményalapot az érvényesítők között
A győztesek nagy valószínűséggel azok az érvényesítők lesznek, akik a legkövetkezetesebben bírták a játékot, és nagyon szigorúan elhatározták, hogy nyernek.
egyes érvényesítők nem akarnak részt venni, mivel alacsonyan értékelik nyerési esélyeiket, különösen, ha a résztvevők között tiszteletreméltó érvényesítők is vannak
Hogy melyik lehetőséget választja, az Önön múlik
Van még egy pont - egyáltalán nem tény, hogy hívására több tucat validátor siet, hogy részt vegyen a játékban, és azok közül, akik úgy döntenek, hogy megpróbálják, nem mindegyik telepíti és indítja el a csomópontot - általában, Ebben a szakaszban a projektek meglehetősen gyér dokumentációval rendelkeznek, hibákat tapasztalnak, és az időkényszer alatt dolgozó fejlesztők nem válaszolnak túl gyorsan a kérdésekre. Ezért a játék elindítása előtt gondoskodni kell arról is, hogy milyen műveleteket hajtsanak végre, ha nem éri el a szükséges számú érvényesítőt. Ebben az esetben a játék elején a hiányzó validátorokat a projektcsapat elindítja, konszenzusban vesznek részt, de nem lehetnek nyertesek.
Következtetés
Végezetül megpróbáltam összeállítani a fentiekből egy listát arról, hogy mit kell kitalálni, elkészíteni és elindítani egy validátor játék hatékony lebonyolításához.
Mit kell tenned egy igazi validátor játék futtatásához:
fejlessz saját blokkláncot :)
- webes felület készítése és létrehozása, valamint CLI biztosítása az érvényesítők szavazásához
- győződjön meg arról, hogy egy futó érvényesítő csomópont metrikáit el lehet küldeni egy központi szolgáltatásnak (például a Prometheusnak)
- hozzon létre egy metrikagyűjtő szervert (Prometheus + Grafana) a validátor játékhoz
- találja ki, hogyan számítják ki az érvényesítő pontokat (VP).
- készítsen egy nyilvános szkriptet, amely a blokkláncból származó adatok alapján kiszámítja a validátor VP-t
- webes felület kidolgozása a legjobb érvényesítők megjelenítésére, valamint az érvényesítők játékállapotára (mennyi idő van még hátra a végéig, kinek mennyi VP-je van, stb.)
- tetszőleges számú saját csomópont indításának fejlesztése és automatizálása, az érvényesítők játékhoz való csatlakoztatásának folyamata (mikor és hogyan kell leválasztani a csomópontokat, leadni és eltávolítani rájuk szavazatokat)
- számolja ki, hány tokent kell kiadni, és dolgozzon ki egy csaptelep szerződést
- benchmark szkript készítése (tokenátvitel, hatalmas tárhelyhasználat, tömeges hálózathasználat)
- gyűjtsd össze az összes résztvevőt egy csevegésben a gyors kommunikáció érdekében
- indítsa el a blokkláncot valamivel korábban, mint a játék kezdete
- várja meg a kezdőkockát, indítsa el a játékot
- tesztelje a hálózatot többféle tranzakcióval
- kemény villát kinyújtunk
- módosítsa az érvényesítők listáját
- ismételje meg a 13,14,15., XNUMX., XNUMX. lépéseket különböző sorrendben a hálózat stabilitásának megőrzése érdekében
- várja meg az utolsó blokkot, fejezze be a játékot, számolja meg a GYP-t
Azt kell mondanunk, hogy a validátorok játéka egy új történet, és csak néhány alkalommal készült, ezért ezt a szöveget nem szabad kész útmutatónak tekinteni. A modern informatikai üzletágban nincsenek analógok – képzeljük el, hogy a bankok a fizetési rendszer elindítása előtt versenyeznek egymással, hogy ki lesz a legjobb az ügyféltranzakciók lebonyolításában. A hagyományos megközelítések valószínűleg nem segítenek nagy decentralizált hálózatok létrehozásában, ezért sajátítson el új üzleti modelleket, futtassa a játékait, azonosítsa az arra érdemeseket, jutalmazza őket, és tartsa az elosztott rendszereket gyorsan és stabilan.
Forrás: will.com