Tehát, a csapatod befejezte a blokkláncod alpha verzióját, és itt az ideje elindítani a testnetet, majd a mainnetet. Van egy valódi blokkláncod, független résztvevőkkel, jó gazdasági modellel és biztonsággal, megtervezted a kormányzást, és most itt az ideje, hogy mindezt a gyakorlatban is kipróbáld. Az ideális kripto-anarchikus világban feltöltöd a genesis block-ot, a végső node kódot, és a validátorok mindent maguktól indítanak, felhajtják az összes segédszolgáltatást, és minden magától megtörténik. De ez egy kitalált világ, a valóságban a csapatnak sok segédszoftvert és különböző manipulációkat kell készítenie ahhoz, hogy segítsen a validátoroknak elindítani egy stabil hálózatot. Erről szól ez a cikk.
A konszenzus-alapú hálózatok, mint például a „proof-of-stake”, ahol a validátorokat a rendszer token-tulajdonosainak szavazatai határozzák meg, indítása meglehetősen speciális feladat, hiszen még a hagyományos, központosított irányítású rendszerek, amelyek tucatnyi és több száz résztvevővel működnek, szerverek önmagukban sem egyszerű feladat, és a blokkláncot hűséges, de független résztvevők segítségével kell elindítani. A vállalaton belül az adminisztrátoroknak teljes hozzáférésük van minden géphez, naplóhoz és közös monitoringhoz, a validátorok azonban nem engedik be a szervereikhez senkit, és valószínűleg inkább önállóan építik fel az infrastruktúrájukat, hiszen ez ellenőrzi a validátorok alapvető eszközeihez — a szavazási stakjükhöz — való hozzáférést. Ez a viselkedés teszi lehetővé a decentralizált, biztonságos hálózatok létrehozását — a használt felhőszolgáltatók, virtuális és
Ezért minden blockchain indítási és üzemeltetési folyamatot úgy kell megszervezni, hogy bármely validátor, vagy akár egy kis csoport validátor is bármikor ki tudja dobni a számítógépeit az ablakon, és el tudjon menni anélkül, hogy bármi is megsérülne, és a megmaradt validátoroknak továbbra is hatékonyan kellene fenntartaniuk a hálózat működését, valamint új validátorokat csatlakoztatniuk. A hálózat indításakor, amikor az egyik validátor Európában, a másik Dél-Amerikában, a harmadik pedig Ázsiában van, meglehetősen nehéz elérni, hogy több tucat független csoport összhangban működjön és érdeklődjön az eredmény iránt.
Validátorok
Képzeljünk el egy hipotetikus modern blockchain indítást (a leírtak nagy része bármely modern blockchain családra vonatkozik: Ethereum, EOS, Polkadot, Cosmos és mások, ahol proof-of-stake konszenzus van. Az ilyen blockchaineken a főszereplők a validátor csapatok, akik saját független szervereik telepítésével foglalkoznak, validálják és új blokkokat hoznak létre, és jutalomban részesülnek a hálózat által, amely azoknak jár, akik részt vesznek a konszenzusban. Az új hálózatok indításához több tucat validátor szükséges (ennyien képesek többé-kevésbé hatékonyan konszenzust elérni másodpercek alatt), ezért a projekt nyilvános regisztrációt hirdet, amely keretében a validátorok megosztják a nyilvános információkat magukról a felhasználókkal, meggyőzve őket arról, hogy minőségi szolgáltatást fognak nyújtani az indított hálózat számára.
A validátorálás egy olyan üzlet, ami lehetővé teszi a validátor potenciális bevételének rendkívül pontos becslését, gyorsan átviheti a kapacitásokat a projektek között, és a kiválasztott hálózat sikerénél a validátor teljes jogú DAO résztvevőként és felelősként fejlesztheti a projektet, vagy egyszerűen kiváló technikai szolgáltatást nyújthat teljesen átlátható, tisztességesen megszerzett pénzért. A validátorok számára a projektek próbálnak figyelembe venni a validátorok költségeit, és úgy alakítani a blokkjutalmakat, hogy ez az üzlet nyereséges legyen, de ugyanakkor ne zúzza össze a gazdaságot, elárasztva őket pénzzel és megfosztva a többi felhasználót a hálózaton.
A validátorok üzlete magas rendelkezésre állást igényel, ami magas szintű devops és fejlesztői felkészültséget, valamint drága számítási erőforrásokat jelent. Még akkor is, ha nincs szükség hash-ek bányászására proof-of-work hálózatokban, egy blokklánc csomópont egy nagy szolgáltatás, amely sok memóriát igényel, sok számítást fogyaszt, és nagy mennyiségű adatot validál, rögzít a lemezen és ad át a hálózatnak. A tranzakciós napló és a blokklánc láncok tárolásához, amelyek több ezer kis tranzakciót tartalmaznak blokkanként, most 50 Gb vagy annál nagyobb tárolóra van szükség, és ez SSD kell legyen. A state database képes megugrani a 64Gb RAM-ot, különösen a smart contractot támogató blokkláncoknál. Az ilyen követelményekkel rendelkező szerverek meglehetősen drágák, az Ethereum vagy EOS csomópont havi költsége 100 és 200 $ között mozog. Ehhez jön még a fejlesztők és devops körüli munka díjának emelkedése, akik a bevezetés alatt gyakran éjszaka oldanak meg problémákat, mivel a validátorok egy része könnyen a másik féltekén tartózkodhat. Mindazonáltal a sikeres időszakokban a validátor csomópont birtoklása jelentős bevételt hozhat (az EOS esetében akár 10 000 $-t is naponta).
A validálás csupán egy új potenciális IT-szerep az üzletemberek és cégek számára, ahogy a programozók egyre kifinomultabb algoritmusokat találnak ki, amelyek jutalmazzák a tisztességet és büntetik a csalást és lopást. Ily módon jelennek meg olyan szolgáltatások, amelyek fontos adatok (orákulumok) közzétételét végzik, felügyeletet látnak el (letét slashing és csalók büntetése a csalás bizonyítékának közzétételével), viták rendezésére szolgáló szolgáltatások, biztosítások és opciók, sőt a garbage collection is potenciálisan nagy piac a smart contract rendszerekben, ahol a tárolásért kell fizetni.
A blokklánc indításának problémái
A blokklánc átláthatósága, amely lehetővé tette, hogy bárki szabadon részt vehessen a számítógépek hálózatának működésében bármilyen országból, és hogy bármely script kiddie könnyen csatlakozhasson a hálózathoz egy GitHub-utasítás alapján, nem mindig előny. Az új token utáni hajszában a validátorokat gyakran arra ösztönzik, hogy „bányásszanak új érmét a kezdetekkor”, bízva a kurzus emelkedésében és a gyors eladás lehetőségében. Ez azt is jelenti, hogy bármilyen anonim személy lehet a validátorod, akire ugyanúgy lehet szavazni, mint más validátorokra (bár az anonim személynek nehézséget okoz megszerezni a stakholder-ek szavazatait, ezért a rémtörténeteket az anoním kriptovalutákról inkább hagyjuk a politikusoknak). Ennek ellenére
A projekt csapatának feladata — valahogy megszerezni azokat, akik a jövőben képesek biztosítani a csomópontok stabil működését, értenek a biztonsághoz, gyorsan megoldják a problémákat, együttműködnek más validátorokkal és közösen cselekednek — ezek a tulajdonságok teljes mértékben befolyásolják azt a bizonyos tokent, amelybe a hálózati résztvevők időt és erőforrásokat kívánnak befektetni. A kellő képességekkel rendelkező alapítók, akik mérlegelik a kockázatokat, jól tudják, hogy egy ilyen volumenű szoftver elindításakor elkerülhetetlenül szembesülni fognak a kódban és a csomópontok konfigurációjában fellépő hibákkal, és hogy a hálózat stabilitása attól függ, mennyire jól tudják a fejlesztők és a validátorok közösen megoldani az ilyen problémákat.
A csapat készen áll, hogy a mainnet-en szavazzon bármely validátorra, de csak tudnák, hogy mire, melyek a jók? A legnagyobb portfólióval rendelkezőre? Jelenleg szinte senkinek sincs. A Linkedin profilok alapján? A tapasztalt DevOps vagy biztonsági szakemberek nem fognak neked semmilyen profilt adni Linkedin-en. A csetben tett nyilatkozatok, posztok és mások segítése a felkészülés során? Ez jó, de szubjektív és pontatlan.
Ilyen körülmények között csak egy dolog marad — ami jól megoldja mindannyiuk problémáit — egy játék, amelyben választhatod a legjobb validátorokat, de ami a legfontosabb — ellenőrizd a blokkláncot az ellenállására és végezz átfogó harci tesztet a blokkláncon aktív használat, a konszenzus változásai, hibák megjelenése és javítása közepette. Ezt a folyamatot elsőként a Cosmos projekt csapata indította el játék formájában, és ez az ötlet kétségtelenül nagyszerű módja a hálózat felkészítésének egy megbízható és hibatűrő mainnet bevezetésére.
A Validátorok Játéka
Leírom a validátorok játékát úgy, ahogy azt a DAO.Casino (DAOBet) blokklánc számára terveztük, amely az EOS forkján alapul, és Haya a neve, és hasonló governance mechanizmussal rendelkezik – a validátorokat szavazások útján választják ki bármely számláról, ahol a validátorra szavazásra használt egyenleg egy része le van fagyva. Bármely számla, amelynek van BET nevű alap tokenje, szavazhat bármely kiválasztott validátorra a saját egyenlegének bármely részével. A szavazatok összeadódnak, és a végeredményként top validátorok listája készül. Különböző blokkláncoknál ezt a folyamatot másképp szervezik meg, és általában pontosan ebben a részben különbözik az új blokklánc az eredetitől, és el kell mondanom, hogy a mi esetünkben az EOS teljes mértékben megindokolja az „OS” szót a nevében, valóban az EOS-t használjuk alapműködési rendszerként a DAOBet feladataihoz módosított blokklánc verziójának bevezetéséhez.
Különböző problémákat és azt, hogy hogyan lehet ezeket megoldani a játék keretein belül, fogom leírni. Tegyük fel, hogy van egy hálózat, ahol a szervered nyíltan támadható, ahol a validátor pozíciójának fenntartásához folyamatosan kapcsolatban kell állnod a hálózattal, előmozdítva a validátorodat, és figyelned kell, hogy az blokkokat termeljen és azokat időben eljuttassa a többi validátorhoz, különben a validátor ki lesz dobva a listából.
Hogyan válasszuk ki a top nyerteseket?
A játékhoz kapcsolódó fő technikai követelmény, hogy az eredményei nyilvánosan ellenőrizhetőek legyenek. Ez azt jelenti, hogy a játék eredményei: a nyertesek TOP listája, szigorúan az alapján kell, hogy készüljön, amit bármely résztvevő ellenőrizhet. Egy centralizált rendszerben mérhetnénk az egyes validátorok „fennállási” idejét, és jutalmazhatnánk azokat, akik a legtöbbet voltak online, vagy akik a legtöbb hálózati forgalmat engedték át. Összegyűjthetnénk az adatokat a processzor terheléséről, a memóriáról és jutalmazhatnánk azokat, akik becsületesen dolgoztak. De bármilyen ilyen metrikagyűjtés centrumának létét jelenti, és ráadásul a csomópontok mind függetlenek, és úgy viselkedhetnek, ahogy akarnak, és bármilyen adatokat küldhetnek.
Ezért a természetes megoldás az, hogy a győzteseket a blokkláncból származó adatok alapján kell meghatározni, mivel ez megmutatja, hogy a validátorok melyik blokkot termelték és mely tranzakciók kerültek be abba. Ezt a számot Validator Points-nak (VP) neveztük el, és ezek megszerzése a validátorok fő célja a játékban. Az esetünkben a validátor "hasznosságának" legegyszerűbb, nyilvánosan ellenőrizhető és hatékony metrikája a VP = a validátor által egy adott időszak alatt termelt blokkok száma.
Ez az egyszerű választás azzal magyarázható, hogy az EOS governance már számos felmerülő problémát figyelembe vesz, mivel az EOS három generáció valóban működő blokklánc örököse, amelyek nagy tapasztalattal rendelkeznek a hálózat összetett irányításában. A validátor bármilyen problémája a hálózattal, processzorral vagy adattárral csak egy problémához vezet — kevesebb blokkot ír alá, amiért kevesebb díjat kap, ami újra csak a blokkok aláírásának számához vezet — az EOS esetében ez egy remek és egyszerű megoldás.
Más blokkláncok esetében a Validator Points számításának módja eltérhet, például a pBFT-alapú konszenzusok (Tendermint/Cosmos, Parity Substrate Aura konszenzus) esetében, ahol minden blokkot több validátor alá kell írjon, értelme van a validátorok egyedi aláírásainak számolásának a blokkok helyett, talán figyelembe kell venni a be nem fejezett konszenzus köröket is, amelyek más validátorok erőforrásait használják fel, összességében ez erősen függ a konszenzus típusától.
Hogyan modellezzük a valódi üzemeltetési körülményeket
A fonder feladata, hogy a validátorokat valósághoz közeli körülmények között ellenőrizzék, mindezt pedig központosított ellenőrzés nélkül. Ezt a problémát egy faucet szerződés segítségével lehet megoldani, amely egyenlő mennyiségű alap tokent oszt ki a validátoroknak és minden érdeklődőnek. A tokenek egyenleghez való hozzáféréséhez tranzakciót kell létrehozni, és el kell érni, hogy a hálózat beillessze azt egy blokkba. Így a validátor számára a győzelemhez folyamatosan új tokenekkel kell feltöltenie az egyenlegét és saját magára kell szavaznia, hogy előre kerüljön. Ez a tevékenység folyamatos terhet jelent a hálózatra, és a paramétereket úgy lehet beállítani, hogy a kérés áramlása elegendően komoly legyen a hálózat teljeskörű teszteléséhez. Ezért előre tervezze meg a faucet szerződést, mint a hálózat indításának fontos eszközét, és kezdje meg a paramétereinek előkészítését.
A tokenek kérése a faucet-ből és a validátorok szavazása még mindig nem teljesen őszintén szimulálja a blokklánc működését, különösen a rendkívül terhelt módokban. Ezért a blokklánc csapatának mindenképpen írnának kiegészítő benchmarkokat, amelyek lehetővé teszik a hálózat terhelését. Különösen fontos szerepet játszanak ebben a korábban létrehozott okos szerződések, amelyek lehetővé teszik egyes alrendszerek tesztelését. A tároló teszteléshez a szerződés véletlenszerű adatokat ment a blokkláncra, míg a hálózati erőforrások ellenőrzésére a teszt szerződés nagy mennyiségű bemeneti adatot követel, így növelve a tranzakciók számát – a tranzakciók áramlásának indításával a csapat egyszerre teszteli a kód stabilitását és a validátorok megbízhatóságát.
Egy külön kérdés a node-ok kódjának frissítése és a hard forkok végrehajtása. Szükséges, hogy baj, sebezhetőség vagy rosszindulatú validátorok összeesküvése esetén a validátoroknak legyen egy előre kidolgozott cselekvési terve, amit a validátorok játékában már begyakoroltak. Itt ki lehet találni VP-kiadásokat a hard fork gyors alkalmazásáért, például büntetve az összes validátort, aki még nem telepítette az új node kódverziót, de ez nehezen megvalósítható, bonyolítja a számítást. Vészhelyzeti hard fork alkalmazásának szimulálására mesterségesen
Hogyan tájékoztassuk a résztvevőket a hálózat állapotáról és javítsuk ki a hibákat
A validátorok közötti bizalmatlanság ellenére előnyös mindenki számára, ha időben aktuális információkat kapnak a hálózat állapotáról, hogy gyorsabban tudjanak döntéseket hozni, így a projektcsapat egy olyan szolgáltatást indít, amely összegyűjti és vizualizálja a validátorok szervereiről származó számos metrikát, lehetővé téve a helyzet egyidejű megtekintését az egész hálózatra vonatkozóan, így gyorsan meghatározható, mi történik. Emellett a validátoroknak és a projektnek is előnyös, hogy a projektcsapat gyorsan javítsa a felfedezett hibákat, ezért a metrikák gyűjtése mellett hasznos lehet a validátorok gépeiről a naplók és hibainformációk azonnali gyűjtésének elindítása egy olyan gépre, amely a blokklánc fejlesztői számára hozzáférhető. Itt senkinek sem érdeke az információ elferdítése, ezért ezeket a szolgáltatásokat a projektcsapat indítja, és ezekre lehet bízni. Érdemes a validátoroktól rendszeres metrikákat gyűjteni, és feltétlenül a blokklánc legfontosabb metrikáit — a DAOBet esetében ez a véglegesítési idő és az utolsó véglegesített blokk elmaradása. Ennek köszönhetően a csapat látja a memóriafogyasztás növekedését a node-oknál a benchmark futtatásakor, a különböző validátorok problémáit.
Fontos szempontok a validátorok játékának lebonyolításához
Mint a különösen fontos jogi szövegben meg kell fogalmazni a validátorok közötti gép támadási jogszerűségét, hiszen egyes országok törvényei alapján a DDoS vagy egyéb hálózati támadások büntetéshez vezethetnek. Fontos kérdés a validátorok jutalmazásának módja is. A természetes díjakat a projekt tokenjei képviselik, amelyeket átvisznek a mainnetre, de a tokenek tömeges elosztása bárkinek, aki el tud indítani egy node-ot, szintén nem a legjobb megoldás. Valószínűleg egyensúlyoznia kell a két szélsőség között:
A teljes nyereményalapot oszd el a megszerzett VP szerint
ez nagyon demokratikus, és lehetőséget ad mindenkinek, aki időt és erőforrást fektetett a validátorok játékába
de vonza a játékba a felkészületlen infrastruktúrával rendelkező embereket
A nyereményalapot oszd el a top-N validátornak a játék eredményei alapján
a győztesek valószínűleg azok a validátorok lesznek, akik a legstabilabbak voltak a játék alatt, és nagyon elszántak a győzelemre
a validátorok egy része nem kíván részt venni, alacsonyan értékelve győzelmi esélyeiket, különösen, ha tapasztalt validátorok is a résztvevők között vannak
Melyik lehetőség élvez előnyt — az Ön döntése
Van egy másik szempont is — nem biztos, hogy tucatnyi validátor fog részt venni a játékban az Ön hívására, és azok közül, akik kipróbálják, nem mindenki telepíti és indítja el a node-ot - általában ebben a szakaszban a projektek dokumentációja meglehetősen szegényes, hibák előfordulhatnak, és a fejlesztők nem mindig válaszolnak gyorsan a kérdésekre. Ezért a játék indítása előtt figyelembe kell venni, hogy mi a teendő, ha a kívánt számú validátort nem sikerül összegyűjteni. Ilyen esetben a játék indításakor a hiányzó validátorokat a projekt csapata indítja el, részt vesznek a konszenzusban, de nem lehetnek győztesek.
Zárás
Végül próbáltam összeszedni a fentiekből egy listát arról, hogy mit kell kitalálni, megvalósítani és elindítani a validátorok játékának hatékony lebonyolításához
Mit kell tenni a valódi validátori játék indulásához:
fejleszteni kell a saját blokkláncodat 🙂
- webinterface-t kell készíteni és CLI-t kell biztosítani a validátorok szavazásához
- Olyan módon kell beállítani, hogy a futó validátor nodok metrikái a központosított szolgáltatásba (például Prometheus) küldésre kerüljenek.
- Emeljük fel a metrikagyűjtő szervert (Prometheus + Grafana) a validátorok játékához.
- Ki kell találni, hogyan fognak számolni a Validator Points (VP) pontszámokat.
- Fejlesszünk ki egy nyilvános scriptet, amely a blokklánc adatai alapján számolja a validátor VP-jét.
- Fejlesszünk ki egy webes felületet a top validátorok és a validátorok játékának állapotának megjelenítésére (mennyi idő van hátra, kinek mennyi VP-je van stb.).
- Fejlesszünk ki és automatizáljunk egy tetszőleges számú saját node indítást, tervezd meg a validátorok játékhoz való csatlakozási folyamatát (mikor és hogyan kell leállítani a saját node-okat, leadni és visszavonni a szavazatokat).
- Számold ki, mennyi tokent kell kiosztani, és fejleszd ki a kontraktus-faucet-t.
- Készíts egy benchmark scriptet (tokenátviteli műveletek, tároló intenzív használat, hálózati intenzív használat).
- Gyűjtsd össze az összes résztvevőt egy chatben a gyors kommunikáció érdekében.
- Indítsd el a blokkláncot kicsit a játék kezdete előtt.
- Várj a kezdő blokkra, kezdd el a játékot.
- Teszteld a hálózatot többféle tranzakcióval.
- Vidd életbe a hardfork-ot.
- Módosítsd a validátorok listáját.
- Ismételd meg a 13., 14., 15. pontokat különböző sorrendben, miközben fenntartod a hálózat stabilitását.
- Várj a végső blokkra, fejezd be a játékot, számold ki a VP-t.
Fontos megjegyezni, hogy a validátorok játéka új történet, és mindössze néhány alkalommal zajlott, így ezt a szöveget ne tekintsd kész útmutatónak. Nincsenek analógok a modern IT üzletágban — képzeld el, hogy a bankok a fizetési rendszer bevezetése előtt versenyeznek egymással, hogy ki tudja jobban lebonyolítani az ügyfelek tranzakcióit. A hagyományos megközelítések nem valószínű, hogy segítenek nagy decentralizált hálózatok létrehozásában, így javasoljuk, hogy saját üzleti modelleket tanulmányozz, tarts játékokat, jelöld ki a méltókat, jutalmazd őket, és engedd, hogy a te elosztott rendszereid gyorsan és stabilan működjenek.
Forrás: habr.com
