Utazás hitelesítővé váláshoz az Ethereum 2.0 2. részében

blog 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressHírlevelek

Iratkozzon fel hírlevelünkre.

Email cím

Tiszteletben tartjuk a magánéletét

HomeBlogDevelopers

Utazás hitelesítővé váláshoz az Ethereum 2.0 2. részében

Milyen szempontokat kell figyelembe venni, amikor kiválasztja a hardvert és a szoftvert az Ethereum 2.0 validator kliens futtatásához? Készítette Coogan Brennan 2020. december 5. Feladva 2020. december 5-én.

Utazás hitelesítővé válni az Ethereum 2 0 2. részében

Megjegyzés: Még mindig hitelesítővé válhat az Ethereum 2.0 hálózaton! Várakozási idő lesz aktiválva validátorként – 2020. december 4-től a várakozási idő nagyjából 9,9 nap. A sorozat 1. részében olvassa el a játékba lépés lépéseit.

  1. Jogi nyilatkozat
  2. Bevezetés
  3. Validator konfigurációs szempontok
  1. Jövőbeni ellenőrző hardver
  2. Eth1 kliens futtatása vagy nem futtatása?
  3. Virtuális és helyi tárhely
  4. Az Eth2 ügyfél választása és a büntetések elkerülése
  • AWS-példány beállítása
    1. Operációs rendszer
    2. Árazás
    3. Tárolás
    4. Portok
    5. SSH-kulcsok és példányindítás
    6. A Teku telepítése
      1. Követelmények
      2. Telepítse a bináris fájlt
      3. Hozzon létre nem root felhasználót
      4. Hozzon létre systemd szolgáltatást
      5. Dob
      6. Jogi nyilatkozat

        Ez egy bejegyzés, amelyet a ConsenSys alkalmazottjaként írok, és aki a jeladó láncot tervezi. Az előbbi kijelentés azt jelenti, hogy a ConsenSys termékeket prioritásként kezelem (a ConsenSys termékek általában az osztályban a legjobbak az Ethereum számára, és hozzáférhetek mérnöki csapatokhoz is, akik segíthetnek a kérdések megválaszolásában és a hibaelhárításban). Ez utóbbi állítás azt jelenti, hogy a költségekre és a könnyű használatra optimalizálok: Nincs több ezer ETH-m, hogy érdemi jutalmat nyújtsak, ezért néhány parancsikont választok. Ezeket a döntéseket hoztam, hogy az Ethereum 2.0-n való részesedést a lehető legegyszerűbbé és hozzáférhetőbbé tegyem az egyének számára, de kompromisszumokkal járnak a decentralizáció és a magánélet terén. Kövesse azonban az alábbi oktatóanyag nagy vonásait, és különböző döntéseket hozhat. Valójában, ha ezt megteheti, arra bátorítalak! 

        Végül az Ethereum 2.0-ban való részvétel rendkívül kísérleti jellegű és hosszú távú elkötelezettséggel jár (három évet osztok ki). Kérjük, ne vegyen részt, ha nem érzi jól magát a magas kockázatú kísérő, és valami még fejlesztés alatt áll. Ha nem biztos abban, hogy részesednie kellene-e, kérjük, csatlakozzon a ConsenSys viszály és kérdezd meg a # teku-public csatornán. 

        Bevezetés

        Az előző bejegyzésben megvitattuk az Ethereum 2.0 bevezetésének okait, és végigjártuk a 32 ETH megszerzését az Ethereum 1.0 mainnet betéti szerződésében. Érintettük a kulcsgenerálást és a tét folyamatát Indítóállás az Ethereum 1.0-t 2.0-hoz kapcsolja.

        November 23-án teljesült az Ethereum 2.0 elindításához az ETH minimális mennyisége – kb. 524 288 -. Az emberek továbbra is részt vehetnek a szerződésben, és az érvényesítők száma december 4-én 33 000 fölé emelkedett.

        Aaron Davis, a MetaMask munkatársa megosztja gondolatait a belső ConsenSys Slack staking csatornán 

        Noha rendkívül izgalmas volt érvényesítőként bekerülni a Genesis blokkba, másodpercekkel később hasonló tapasztalatokat szereztem Aaron Davis kollégámmal a belső ConsenSys stakes csatornánkon: Milyen őrült feladatra jelentkeztem? Szerencsére hihetetlenül briliáns és technikás emberekhez van hozzáférésem ahhoz, hogy elég jótékonysági tevékenységet folytassak, hogy tippeket, tanácsokat és betekintést nyújtsak ennek a rubelnek a staking infrastruktúra működtetésével kapcsolatban. Remélem, hogy ennek az értékes tanácsnak a töredékét átadom itt más érdekelt feleknek.


        Ez lesz a cikk első része: Milyen szempontokat kell figyelembe vennie, amikor kiválasztja a hardvert és szoftvert az Ethereum 2.0 validator kliens futtatásához? A második rész az adott hardver / szoftver kombinációt mutatja be, amelyet az érvényesítő klienshez választottam. A konfigurációval kapcsolatos döntések az erőforrásoktól, a személyes hajlandóságtól és a technikai képességektől függenek. Mindent megteszek annak érdekében, hogy rávilágítsak arra, hogy a személyes elfogultság és körülmények miként adták meg a döntéseimet.

        Végül, mielőtt belevágnánk, szeretném megismételni, hogy ezek a hozzászólások szinte olyanok, mint a folyóirat-bejegyzések a 32 ETH megszerzésével kapcsolatos tapasztalataim alapján (igaz, naplóbejegyzések kiterjedt technikai szempontokkal). Mint ilyen, kissé megváltoztathatom a szemléletemet a jeladó lánc előrehaladtával. Például arra gondoltam, hogy mindenképpen használni fogom az AWS-t. Amint alább olvassa, ezt most újragondolom. A tét pénzügyi elemét is nagyon tisztán fogom tudni. A staking az Ethereum ökoszisztéma támogatásának egyik módja, de a fenntartható nyilvános használat érdekében az ETH-val rendelkezõ emberek számára is hozzáférhetõnek és lehetõvé kell tenni.. 

        Jövőbeni ellenőrző hardver

        A validátor futtatásának alapvető követelményei manapság viszonylag könnyen teljesíthetők. Mara Schmiedt és Collin Meyers Validátor útmutató a Bankless-nél eléggé lemerültek a minimális követelmények. Az Ethereum 2.0 validátor felszerelésének meghatározása során a legnagyobb kihívást a Beacon Chain 0 fázis jelenlegi igényeinek és a jövőben még ismeretlen igényeknek az egyensúlyozása jelenti, miközben a fejlesztés folytatódik. (Ez nem okoz gondot, ha kényelmesen figyeli a hitelesítőt, és képes gyorsan és egyszerűen kezelni a változásokat.) 

        Ben Edgington, a Teku projektmenedzsere és a Eth2.hírek, rendelkezésemre bocsátott néhány olyan éles esetet, amikor a hálózat esetleg többet követel meg az érvényesítő klienstől. Rövid távon a legnagyobb gond az ilyesmi a Medalla időszerver eseménye, amelyben a hiba és az azt követő javítás a Prysm kliensben leállította a véglegesítést a testneten (nagyjából szólva a hálózat nem tudott „blokkokat előállítani”). Mivel a hálózaton nem volt véglegesség (nincsenek „megerősített blokkok”), az érvényesítőknek a szokásosnál sokkal több tranzakciót kellett tartaniuk a RAM-on.. 

        A 8 GB RAM-mal rendelkező gépek – amelyek normál körülmények között már bőven elegendőek lettek volna – „memóriából kifogyott” problémákkal kezdtek találkozni, amelyek elveszítéshez vezethettek. Egy ilyen tüske, bár szokatlan, nem kizárt a 0. fázisú mainnet számára.

        A hálózat jövőbeni konfigurációs kétértelműségei az Ethereum 1.0 és 2.0 egyesítése és a szilánkosítás bevezetése. Még mindig nem tudjuk, hogy ezek az egyesülések mikor következnek be, és pontosan mire lesz szükségük. Szeretnék egy erős CPU-gerincet a 0. fázisba (4 virtuális mag, 16 GB-os RAM 100 GB-os SSD-vel), majd a tárterület körüli jövőbeli kiigazításokra összpontosítanám a figyelmemet (itt hagyva a mozgásteret). Felhívjuk figyelmét, hogy ez túlzottnak bizonyulhat, és felemésztheti a tétjutalmakat.

        Ezek a jövő „ismert ismeretlenjei”. Beszéljük meg a validátorok mai fő konfigurációs döntési pontjait.

        Eth1 kliens futtatása vagy nem futtatása?

        Ez egy átjárási rítus, amelyet megpróbálok minél gyakrabban alávetni a bootcamp tanulóinknak: szinkronizálni egy Ethereum 1.0 klienst. Nyílt titok, hogy valójában egy „teljes” Ethereum 1.0 csomópont üzemeltetése a szeretet cselekedete, nem pedig egy edzett, a Rab Dilemma megoldása. A „teljes” -et idézőjelbe kell tenni, mert még az Ethereum alapvető fejlesztői is nehezen tudnak megállapodni a „teljes csomópont” valójában meghatározásában.

        Egy dologban mindannyian megegyezhetünk: Több idő és tárhely szükséges egy Ethereum 1.0 kliens szinkronizálásához, mint azt elképzelnéd. Ellenőrzőinknek rendelkezniük kell az Ethereum 1.0 hálózati adatbázis lekérdezésének módjával (egy kicsit később rájövünk, hogy miért). Ha meg szeretné menteni a helyileg történő szinkronizálás helyét és fejfájását, használhat egy Infura végpontot, amely regisztrációval ingyenesen elérhető. 

        Annak ellenére, hogy ez jelentős tárolási és logisztikai aggályokat takarít meg, egyidejűleg feláldoz egy bizonyos mértékű decentralizációt az Eth1 és az Eth2 hálózatok számára. Ha Infura lemenne, ami rendkívül ritka, de előfordul, ez hullámzó hatást váltana ki az Ethereum 2.0 validátorokban az Ethereum 1.0 végpontjukhoz használva. Valami megfontolandó dolog!

        (Csak hogy tisztázzuk: az Ethereum teljes csomópontjának szinkronizálásának nehézségei az Ethereum világállapot természetéhez kapcsolódnak, nem pedig az Ethereum 1.0 magfejlesztőkhöz, akik elképesztő munkát végeztek ezzel a rendkívül kihívást jelentő problémával.)

        Virtuális és helyi tárhely

        A következő szempont számomra egy validáló csomópont otthoni (otthoni) vagy virtuális (virtuális szolgáltatónál, például az Amazon Web Services (AWS), a Digital Ocean stb.) Tárolása volt. Amint azt az előző cikkben említettem, nem bízom magamban abban, hogy konzisztens ellenőrző csomópontot futtatok otthonról, még egy valahol távol tárolt laptopon is. Ügyetlen és ostoba, vagy felrúgom, vagy megfeledkezem róla.

        Azért döntöttem, hogy az AWS-en futtatom a csomópontomat, mert ez az, amit a legjobban ismerek (Miután végigcsináltam ezt az egész folyamatot, másodszor tippelem ezt a döntést. Ezt később megbeszélem). A kompromisszum itt megint a decentralizáció: ha az AWS csökken, vagy bármilyen problémája van (mint a közelmúltban), Kegyelmükben vagyok. Ha elég sok ember fut csomópontokat az AWS-en, az hatással lehet a nagyobb Ethereum hálózatra.

        Az emberek valószínűleg maguk választják ki ezt. A helyi tárhely egy speciális projekt, és nem mindenkinek van ideje, erőforrásai vagy elkötelezettsége. Noha a virtuális tárhely központosító erő, a használatának egyszerűsége és (remélhetőleg) garantált üzemideje miatt választani szoktam vele. 

        Ha egy érvényesítő csomópontot szeretne futtatni helyben, akkor is követheti ennek az oktatóanyagnak az általános irányát, Somer Esat kiváló oktatósorozata különböző ügyfelekkel vagy még egy 8 GB RAM-mal rendelkező Raspberry Pi Model 4B-t is szinkronizál az Ethereummal az ARM-en. (A Raspberry Pi szinkronizálása még mindig nagyon kísérleti, és az embereknek meg kell várniuk, amíg az Ethereum az ARM csapatában megerősíti stabilitását)

        Az Eth2 ügyfél választása és a büntetések elkerülése

        Egy másik fő választás az Ethereum 2.0 kliens a meglévő kliensek közül: Világítótorony, Vezércsillag, Világító felhő, Prysm és Teku. Nagyon elfogult vagyok a Teku iránt, és nem vagyok elég hozzáértő ahhoz, hogy vitassam az ügyfelek finomabb pontjait. ez a cikk egy megfelelő áttekintés a Medalla kliens teljesítményéről. (Ne feledje, hogy a Medalla sokkal többet követelt a processzoroktól, mint a mainnet.)

        A tét igazolása kifejezetten visszatartó erőket tartalmaz a hálózat helyes viselkedésének ösztönzésére. Ezek a formák: az ellenőrzők offline állapotának dingelése és a szereplők drámaibb lépése, ha rosszindulatúan lépnek fel a hálózat ellen, tudatosan vagy más módon.

        A leggyakoribb probléma az lesz, hogy az érvényesítő elérhető legyen a hálózat számára. Ez azt jelenti, hogy győződjön meg arról, hogy az ellenőrzője online van-e. A DevOps-megközelítés ehhez a kérdéshez – a felügyeleti és riasztási rendszer létrehozása, amely figyelmezteti Önt, ha az ellenőrzője offline állapotba kerül -, itt nem foglalkozom ezzel.

        De van egy másik módja is annak, hogy nem érhető el a hálózat, és ez az, ha az ügyfele egy vagy másik okból rosszul viselkedik. Után az időszerver hibája hálózati lassulást okozott a Medalla-ban, az Eth2 fejlesztői összefogtak a fejlesztés érdekében “[A] A kulcs aláírási előzményeinek átadására szolgáló szabványos formátum lehetővé teszi az ellenőrök számára, hogy könnyen váltsanak az ügyfelek között, anélkül, hogy az ütköző üzeneteket aláírnák.” Nem minden ügyfél rendelkezik ezzel a védelemmel, de a Teku igen. Itt olvashat a Teku Slash Protection használatáról (alapértelmezés szerint fut), beleértve a migrációt a Teku csomópontok vagy a nem Teku csomópontok között a Teku csomópontok között.

        Ha problémája van az ügyfelével, és újra kell indítania a teljes hálózatot, akkor tisztában kell lennie a gyenge szubjektivitással. A munka igazolása lehetővé teszi, hogy bárki visszatérjen a hálózat genezis blokkjára, és megbízhatatlanul építse fel a hálózati állapotot a semmiből. A tét igazolásának azonban van fogása ebben a tekintetben: Ha a hálózati validátorok egyharmada egy bizonyos kijáratnál továbbra is aláírja a blokkokat és az igazolásokat, akkor megváltoztathatják a hálózat állapotát, és ezeket a hamis adatokat a csomópontba szinkronizálják. hálózatot, ha a rosszindulatú szereplők elkapják a szinkronizáló csomópontot, mielőtt a szinkronizáló csomópont odaérne, ahol az érvényesítők visszavonták az alapjaikat. Itt többet olvashat róla, de a rövid válasz az, hogy vagy „gyenge szubjektivitás-ellenőrző ponttal”, vagy kódolt állapotfájllal kell rendelkeznie, lényegében a hálózat archívumával. A Teku induló zászlókat biztosít mindkettő számára.

        Az utolsó büntetési aggodalom a legsúlyosabb: Csapás. A perjel akkor következik be, amikor egy érdekelt fél a hálózat szabályainak megfelelően dolgozik. Ez különbözik attól, hogy megbüntetik az offline módot. Aktívan dolgozik a hálózaton, ellentmondó validátor információk benyújtásával. Van néhány nagyon jó anyag, amellyel többet megtudhat a vágásról és annak megakadályozásáról:

        A fő elvitel nem egy hitelesítő kulcs futtatása több kliensen. Nyilvánvalóan ez okozta a valaha bekövetkezett első pergő eseményt, ami december 2-án történt. Azóta számos vágás történt! Ha egyik példányról a másikra vándorol, négyszer ellenőrizze, hogy nem két gép dolgozik-e ugyanabból a kulcsból:

        Ben papa úgy mondja el, mint van. Forrás

        AWS + Infura + Teku Validator konfigurációs specifikációk

        A Genesis blokk beállítása:

        Operációs rendszer: Ubuntu Server 20.04 LTS (HVM) (Amazon Web Service)

        Processzor: Intel Xeon Platinum 8000 sorozatú processzor, 3,1 GHz. (Amazon Web Service)

        Memória: 4 virtuális mag, 16 GB RAM (Amazon Web Service)

        Tárolás: 100 GB SSD, 300/3000 IOPS (Amazon Web Service)

        Ethereum 1.0 kliens: Infura végpont (szabad réteg)

        Ethereum 2.0 kliens: Teku

        A fenti szempontokat áttekintve nem voltam biztos a validátor beállításának legjobb megközelítésében. Magamnak szeretnék választani egy gépet, és általában nem aggódnom legalább két évig tartó cseréje miatt. Ez segít az általános validátor költségekben (jelentős kedvezményhez juthatok, ha néhány évre bezárkózom egy virtuális szolgáltatóval), és nem vagyok különösebben mozgékony a szerverek felpörgetésében. Ez a jövőbiztos vagy „túlspecifikus” megközelítés remélhetőleg kissé megkönnyíti az életemet a következő két évben.

        Kezdetben biztos voltam benne, hogy az AWS a legjobb virtuális platform, és ez az a szolgáltatás, amelyet a következő és a következő bejegyzéshez használok. Miután azonban végigvittem az egész folyamatot, rájöttem, hogy az AWS túlzott lehet az egyes fejlesztők számára. Úgy tűnik, hogy az AWS valódi erőssége az a képesség, hogy dinamikusan bővüljön a prémium költségekkel járó kereslet kielégítése érdekében. Ennek gazdasági értelme van egy nagyszabású, vállalati szintű projekt, de az egyedi Ethereum 2.0 esetében jelenlegi az ügyfél követelményei nem igényelnek ilyen szigorúságot.

        Folytatom az AWS-t, de egy olyan példány futtatásának lehetőségét is szórakoztatom a Digital Ocean-en, amely megfelelőbb lehet egy-egy fejlesztő számára. Bővebben erről egy későbbi időpontban.

        Az Infura fiók beállítása

        Az Infura használatát választom Ethereum 1.0 végpontként. A jelzőlánc egyelőre figyeli az Ethereum 1.0 betétbiztosítási szerződését, hogy aktiválja az új érdekelteket, miután megfelelően letétbe helyezték a 32 ETH-t és benyújtották a megfelelő BLS aláírásokat.

        A jövőben a jeladó lánc megkezdi a további feldolgozás tesztelését azzal, hogy az Ethereum 1.0 állapotinformációinak felhasználásával párhuzamos ellenőrző pontokat hoz létre a jeladó láncon..

        Mint fent említettük, két fő módja van az Ethereum 1.0 hálózat láthatóságának. Az egyik az Ethereum 1.0 csomópont szinkronizálása és aktív karbantartása, amely helyi Ethereum 1.0 állapotadatot hoz létre. A másik egy olyan szolgáltatás használata, mint az Infura, amely egy egyszerű Ethereum 1.0 végpontot biztosít, amely elérhető HTTPS vagy WebSockets.

        Itt jelentkezzen be fiókjához. Miután megvan a fiókja, kattintson a bal oldalon található Ethereum logóra.

        Kattintson a jobb felső sarokban található „Új projekt létrehozása” elemre

        Nevezze el a projektet (az enyém „Eth 2 Validator”), és lépjen a „Beállítások” részhez, ellenőrizze, hogy a hálózati végpontja „Mainnet”-e, és másolja a HTTPS végpontot:

        Ezt később használjuk a Teku kliens indítási parancsához!

        AWS-példány beállítása

        Az EC2-példány beállítása az Amazon-on egyszerű. Néhány átdolgozásunk lesz itt-ott, hogy segítsünk virtuális példányunknak abban, hogy jól játsszon a Tekuval.

        Hozzon létre egy AWS-fiókot (amely eltér az Amazon.com-fióktól), és jelentkezzen be az AWS Console-ba. Lépjen az EC2 oldalra, amely így néz ki:

        Kattintson a „Példány indítása” gombra. Ezután a következő képernyőt látja:

        Operációs rendszer

        Itt választjuk ki, hogy milyen gépi képet (amelyet operációs rendszernek gondolok) szeretnénk használni a virtuális példányunkon. Az Ubuntu Server 20.04-et választom, ami egy Linux alapú szerver környezet. Az Ubuntu Server környezetben néhány kulcsfontosságú optimalizálási különbség van az Ubuntu Desktop környezettől. Céljaink szempontjából a fő különbség az, hogy az Ubuntu Server nem rendelkezik grafikus felhasználói felülettel (GUI). Merre tartunk, csak parancssor van! Visszatér az Apple II napjaimra.

        Az operációs rendszer kiválasztása után kiválasztjuk a példány típusát:

        Ezt a menüt meglehetősen elsöprőnek találom, ezért egy kicsit lebontom az Ön számára. Itt választjuk ki a számítógépünk magját / RAM teljesítményét / CPU-ját. Ez a gép „nyers” vagy „aktív memóriája”, és elkülönül az eszköz tárolásától (merevlemezétől). Gondoljon arra, mint virtuális példányunk motorjára, amelyen futtatni fogjuk az Ubuntu Server operációs rendszerünket. Az AWS ezeket külön példánycsaládokra osztja szét, amelyeket a bal szélső oszlopban betű / szám kombináció jelöl.

        A példánycsaládok különböző hardveres elrendezéssel rendelkeznek, ahogy a különböző autómotorok is különböző konfigurációjú dugattyúkat, dugókat és üzemanyagokat tartalmaznak, hogy megfeleljenek a különböző igényeknek. Két „általános számítási” példánycsaládjukra fogunk koncentrálni, az m5-re és a t3-ra.

        Az m5.xlarge példányt választom, amely 4 virtuális számítási magot (vCPU) és 16 GB RAM-ot biztosít. Miután egy napig futtattam az Ethereum 2.0 mainnet-t, a gépem nem használta fel a rendelkezésre álló vCPU több mint 4% -át. Amint azt a „Future Proofing” részben említettük, az Ethereum 2.0 hálózati igények csak növekedni fognak. De a következő néhány hónapban, ha nincsenek hosszabb hálózati csúcsok, nagy valószínűséggel jól lennék egy m5.nagy példánnyal (2 virtuális mag / vCPU, 8 GB RAM)

        A nálam ügyesebb technikai emberek a t3.large példányt is ésszerű opcióként ajánlották az Ethereum 2.0-hoz. A t3.large 2 vCPU-val és 8 GB memóriával rendelkezik, ugyanúgy, mint az m5.large, de a t3 család a „burstable” hálózati tevékenységre (a CPU csúcsai) épül, nem pedig az állandó CPU-terhelésekre épített m5 család.

        Árazás

        Az utolsó dolog, amit meg kell említenünk, mielőtt áttérnénk a tárolásra, az ár. Az AWS drága más lehetőségekhez, például a Digital Oceanhez képest. A CPU-t (a példánycsaládját) és a tárhelyet (a merevlemez-meghajtót) külön-külön fizeti az Ön által használt adatok alapján. A CPU-t óránként fizetik. Mivel a validátoroknak 24 órán keresztül online kell lenniük, az alábbi ártáblázat segítségével (2020 decemberétől) néhány durva számítást végezhet: 

        Ezek igény szerinti árak. Az AWS szolgáltat valami ún Fenntartott fokú árképzés, ahol ha azt ígéri, hogy virtuális példánya lesz egy évtől három évig, akár 50-60% -os költségcsökkentést is elérhet a fenti ártáblán. (Köszönet Jason Chromannak ezért a tippért!)

        Az EC2 kezdőlapján kattintson a bal oldalon található „Foglalt példányok” elemre, az alábbiak szerint:

        Kattintson a „Vásárlás lefoglalt példányára”:

        A felbukkanó menüben adja meg a példánytípus adatait és az árképzés megtekintéséhez szükséges időt (az m5.xlarge és 36 hónapos futamidőt választom):

        Kattintson a „Keresés” gombra, és tekintse meg az áropciókat:

        Jelentős árengedmény van, hiszem, hogy meghaladja az 50% -ot, de három évre bezárva vagyok. Miután megvásárolta a Foglalt példányt, az AWS ezt egy meglévő virtuális dobozra alkalmazza, vagy az indítás után alkalmazza. Ne feledje, hogy ez NEM tartalmazza a tárhelyet (merevlemez). 

        Megjegyzés: Még nem teszem ezt, mivel még nem vagyok meggyőződve arról, hogy az AWS a legjobb megoldás egy-három Ethereum 2.0 validátor csomópontot befogadó egyén számára. Igény szerinti árképzéssel működő példányt futtatok, hogy lássam, mi megy, mielőtt elkötelezem magam. 

        Tárolás

        Visszatérve a példányindítási folyamatunkra, áttérünk a „Tárhely hozzáadása” fülre

        A zseniális technikai szakemberek, akikkel konzultáltam, 100 GB-os, általános célú SSD-t ajánlott tárolni. A tárolás általában nem szűk keresztmetszet az Eth2 ügyfeleknél. Ez azonban így van nélkül teljes Eth1 kliens futtatása. Az Eth1 tárolására a konzervatív becslés körülbelül 1 TB lenne. Feltétlenül számoljon ezzel, ha nem az Infurát használja.

        Nem ismerem a fenti képen található IOPS oszlop egységét, de ez a processzorral kommunikáló merevlemez bemeneti-kimeneti pontja. Ez egy klasszikus szűk keresztmetszet a teljes Eth1 csomópont szinkronizáláshoz. Ha teljes Eth1 klienst szeretne szinkronizálni ezen a gépen, és problémái vannak, akkor ez lehet a hely, ahol meg lehet nézni.

        Portok

        Átugorva a „Címkék hozzáadása” lehetőséget, lépjen a „Biztonsági csoport konfigurálása” elemre. Ezek a különféle bejáratok jönnek létre a példánnyal történő különféle bejövő és kimenő kommunikációhoz.

        Az AWS automatikusan megnyitja a hagyományos SSH portot, mivel ez lesz a fő módszer a példánnyal való együttműködésre. Érme kesudió és Somer Esat kiváló útmutatók egyaránt javasolják a jelszóhozzáférés letiltását az SSH számára, de meglátjuk, amikor elindítjuk azt a példányt, amely nem az AWS alapértelmezett opciója. Jó azonban randomizálni az SSH-portot egy 1024-65535 közötti számra. Ennek célja, hogy megakadályozza a rosszindulatú szereplőket abban, hogy a szabványos SSH-portot hálózatban vizsgálják. Nézze meg, hogyan védheti általában az SSH-portot itt és kifejezetten az AWS-hez itt.

        Két biztonsági szabályt kell hozzáadnunk a Teku kliens befogadásához, és ez a peer-to-peer kommunikációhoz kapcsolódik. A blokklánc-hálózatok decentralizáltak abban az értelemben, hogy a csomópontok közvetlenül beszélnek egymással. A központi csomópont megkérdezése helyett az egyes csomópontok kialakítják és fenntartják a hálózati állapot megértését azáltal, hogy sok csomóponton „pletykálnak”. Ez azt jelenti, hogy amikor az egyik ügyfél kezet fog a másikkal, kicserélik a hálózattal kapcsolatos információkat. Elég sokszor megtörtént különböző csomópontokkal, az információ terjed a hálózaton. Jelenleg az Eth2 Validator csomópontomnak 74 társa van, akikkel beszélget.

        A Teku kommunikál a 9000-es port többi csomópontjával, ezért ezt megnyitjuk az UDP és a TCP számára, kétféle kommunikációs protokoll. 

        Utána valami ilyennek kell kinéznie:

        SSH-kulcsok és példányindítás

        Utoljára lépjen az „Ellenőrzés és indítás” részhez, áttekintve a meghozott döntéseket. A jóváhagyást követően megjelenik egy előugró menü az SSH kulcsokról. Az enyémet nem mutatom, mert érzékeny információkat tartalmaz. Nevezetesen, a kulcspár az SSH-n (helyi parancssor) keresztül hitelesített és bejelentkezett a virtuális példányba. Ha még nincs párja, akkor az AWS generál egyet. Ezt le kell töltenie, és úgy kell kezelnie, mint egy Ethereum privát kulcsot! Csak így lehet csatlakozni a példányához, és az AWS nem fogja menteni az Ön számára.

        Miután minden hunky-dory, ez az ablak jelenik meg:

        Oké! Ezzel elkészültünk, térjünk át a példányunk elérésére és biztonságára, majd telepítsük és futtassuk a Tekut!

        Hozzáférés a példányhoz

        Az AWS-példány elérésének fő módja az SSH, „Kriptográfiai protokoll a hálózati szolgáltatások biztonságos üzemeltetéséhez nem biztonságos hálózaton keresztül.” Mint korábban említettük, az AWS alapértelmezés szerint letiltja a jelszó hitelesítést a példány eléréséhez. Csak a példány indítása előtt létrehozott kulcspár használható. A kulcspárnak a.pem fájl végződésűnek kell lennie. 

        Az AWS tiszta módszert kínál az SSH parancs megszerzésére. Az EC2 főoldaláról a futó példányra kattintva a jobb felső sarokban található egy gomb, amely azt mondja, hogy „csatlakozzon”:

        A következő oldalon az Ön példányához tartozó SSH parancs található. A következő felépítésű lesz:

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [e-mail védett]_IDENTIFIER.compute-ZONE.amazonaws.com

        Ha beírja ezt a parancsot egy terminálba, megkezdődik az SSH munkamenet. Az első alkalommal a helyi gép megkérdezi, hogy megbízik-e az AWS által biztosított ECDSA ujjlenyomatban. Ez megakadályozza a ember a középen támadás és ha aggódik, a felhasználó megszerezheti példányának ujjlenyomatát ezeket a lépéseket.

        Az aktuális SSH-munkamenettől különálló terminálban vigye át a Teku futtatásához szükséges érvényesítő kulcsfájlokat. Az előző blogbejegyzésben 32 ETH-t töltöttünk be, és megszereztük az Ethereum 2.0 érvényesítő kulcsait. A végén maradt ez a fájlszerkezet:

        eth2deposit-cli / └── validator_key_info / ├── KEYSTORE-M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        Át kell vinnünk a validator_key_info fájlt a virtuális példányunkba. A Secure Copy Protocol (scp) lehetővé teszi számunkra, hogy ezt biztonságosan elvégezzük. Alkalmazza az alábbi általános scp parancsot a fenti könyvtár elérési útjának és az előző SSH parancs használatával:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [e-mail védett]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (Vegye figyelembe a „: ~” szót a teljes parancs végén.)

        Látnia kell egy fájlátvitelt. Ha visszalép az SSH munkamenethez, és beírja az ls szót, akkor látnia kell az átvitt könyvtárat.

        A Teku telepítése

        Most, hogy megvannak a szükséges ellenőrző fájlok, telepíteni fogjuk a Tekut. Először frissítenünk kell a meglévő programokat és telepítenünk kell a szükséges Java rendszereket:

        Telepítse a Java-t

        sudo apt frissítés && sudo apt install default-jre && sudo apt install default-jdk

        Ellenőrizze, hogy a Java telepítése sikeres volt-e:

        java -verzió

        Telepítse a bináris fájlt

        Itt található a legújabb stabil Teku kiadás. Másolja a link címét a tar.gz fájlba, majd töltse le az SSH munkamenetből. Így nézett ki az enyém, az Ön verziója valószínűleg más lesz:

        göndörítés -JLO https://bintray.com/consensys/pegasys-repo/download_file?file_path=teku-20.11.1.tar.gz

        Távolítsa el a letöltött fájlt a következő paranccsal. Ha másik verziója van, adja meg a fájl nevét a teku-20.11.1.tar.gz helyett:

        tar -zxvf teku-20.11.1.tar.gz

        A tisztaság érdekében távolítsa el a tar.gz fájlt.

        Mindezen lépések után a következőképpen kell kinéznie az otthoni könyvtárnak (a Teku verziószáma és tartalma eltérő lehet:

        ubuntu / └── teku-20.11.1 / ├── ENGEDÉLY ├── bin / ├── lib / ├── licencfüggőség.html ├── teku.autocomplete.sh └── validator_key_info / ├── KEYSTORE -M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        Hozzon létre egy nem root felhasználót

        Ezt a lépést a Somer Esat’s másolja kiváló Ubuntu / Teku bemutató

        Létrehozunk egy nem root felhasználó, teku nevű felhasználót, aki képes kezelni a Tekut. Írja be az alábbiakat:

        sudo useradd –no-create-home –shell / bin / false teku 

        Létrehozunk egy egyedi adatkönyvtárat a Teku számára is, majd hozzáférést adunk a teku felhasználónak ehhez:

        sudo mkdir / var / lib / teku && sudo chown -R teku: teku / var / lib / teku

        Hozzon létre systemd szolgáltatást

        Ezt a lépést a Somer Esat-tól adaptálják kiváló Ubuntu / Teku bemutató

        Ezzel a lépéssel olyan szolgáltatás lesz, amely a háttérben futtatja a Tekut. Ez lehetővé teszi a gép számára, hogy automatikusan indítsa újra a szolgáltatást, ha valamilyen okból leáll. Ez egy szükséges lépés annak biztosításához, hogy az érvényesítőnk 24–7.

        Hozza létre a szolgáltatásfájlt a nano szövegszerkesztő használatával:

        sudo nano /etc/systemd/system/teku.service

        Ebben a fájlban (amelynek üresnek kell lennie) egy sor parancsot fogunk beírni, amelyeket a systemd a szolgáltatás elindításakor hajthat végre. Itt van az alábbi kód, be kell adnia a következő elemeket, amelyeket az utazás során gyűjtöttünk:

        • Infura Eth1 HTTP végpont
        • validator_key_info könyvtár útvonala két érvényes kulccsal kapcsolatos fájllal
        • Egyéni adatútvonal (lib / var / teku)

        Helyezze ezeket az értékeket az alábbi félkövér kódba, majd másolja át az egészet a nano szövegszerkesztőbe:

        [Egység] Leírás = Teku Beacon Node Wants = network-online.target After = network-online.target [Service] Type = simple User = teku Group = teku Restart = always RestartSec = 5 ExecStart = / home / ubuntu / teku-20.11 .1 / bin / teku –network = mainnet –eth1-endpoint = INFURA_ETH1_HTTP_ENDPOINT_GOES_HERE – érvényesítő-kulcsok = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json: /home/ubuntu/validator_key_info/validator_keys/KEYST45 –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled – validátorok-kulcstár-zárolás-engedélyezett = hamis –adatbázis-elérési út = / var / lib / teku [Telepítés] WantedBy = multi-user.target

        Írja be az X parancsot, majd írja be az „Y” parancsot a módosítások mentéséhez

        A frissítéshez újra kell indítanunk a „systemctl” -t:

        sudo systemctl daemon-reload

        Indítsa el a szolgáltatást:

        sudo systemctl start teku

        Ellenőrizze, hogy rendben van-e:

        sudo systemctl status teku

        Ha hibát észlel, futtasson további részleteket:

        sudo journalctl -f -u teku.szolgáltatás

        A Futtatással leállíthatja a Teku szolgáltatást:

        sudo systemctl stop teku

        Ellenőrizze a Teku hibaelhárítási oldalát, hogy vannak-e gyakori hibák, ill nézd meg a Teku viszályt, amelyet a csapat figyel.

        Miután úgy érzi, hogy rendbe hozták a dolgokat, engedélyezze a szolgáltatás újraindítását, ha futással leáll:

        sudo systemctl engedélyezi a tekut

        Tessék, itt van! A dolgoknak éppen most kell főzniük. A Teku szolgáltatás ellenőrzésekor egy naplósorozat jelenik meg, amely megjegyzi a szinkronizálási eseményt. Ez az Ön hitelesítője szinkronizálja a jeladó láncot. Amint eléri a fejét, ezek a naplók a Nyerőhely-beolvasásra váltanak, és látni fogja az igazolási teljesítményét és blokkolja a javaslatokat.

        Dob

        Forrás: Beaconcha.in

        December 1-én, UTC szerint 12 órakor a Beacon Chain első blokkjait validálták. Az első blokk jött Validator 19026, a rejtélyes falfirkákkal: „Mr. F itt volt.” Tizenkét másodperccel később jött a következő blokk, graffiti jelezve, hogy a validátor található Zug, Svájc. Az Eth2 Beacon lánc folyamatosan növekedett, blokkról blokkra 12 másodpercenként. Aztán jött a következő akadály: elegendő validátor lenne online az első korszak véglegesítéséhez? Igen! A validátorok 82,27% -a igazolta a 0-as korszak érvényességét, a Beacon Chain közmondásos földszintjét. A Beacon Chain bevezetéséről és a továbbiakról itt olvashat bővebben. 

        Forrás: Beaconcha.in

        Most az Epoch 760-on vagyunk, ami azt jelenti, hogy a Beacon lánc majdnem egy hete zavartalanul működik. 

        Íme egy kép a genezis pillanatának szemszögéből, az ebben a bejegyzésben leírt beállítás segítségével:

        A következő részletben összefoglaljuk a dolgok menetét. Hozzá fogok férni a Teku mutatóihoz, megvitatom az AWS futtatásának költségeit és röviden megvitatom a hálózat állapotát.

        Maradjon velünk!

        Források és linkek

        Köszönet: James Beck, Meredith Baxter, Jason Chroman, Aaron Davis, Chaminda Divitotawela, Ben Edgington, The Dark Jester, Somer Esat, Joseph Lubin, Collin Meyers, Nick Nelson, Mara Schmiedt, Adrian Sutton és Alex Tudorache a támogatásért és a technikai segítségért.

        Feliratkozás hírlevelünkre a legfrissebb Ethereum-hírekről, vállalati megoldásokról, fejlesztői erőforrásokról és egyebekről. E-mail cím

        Mike Owergreen Administrator
        Sorry! The Author has not filled his profile.
        follow me
        Like this post? Please share to your friends:
        Adblock
        detector
        map