سفر من به اعتبار سنجی شدن در Ethereum 2.0 ، قسمت 2

NewsDevelopersEnterpriseBlockchain ExplainedEvent ها و کنفرانس ها Pressخبرنامه ها

مشترک شدن در خبرنامه ما.

آدرس ایمیل

ما به حریم خصوصی شما احترام می گذاریم

صفحه اصلی وبلاگ توسعه دهندگان

سفر من به معتبر شدن در Ethereum 2.0 ، قسمت 2

برخی از مواردی که هنگام انتخاب سخت افزار و نرم افزار برای اجرای یک مشتری اعتبار سنج Ethereum 2.0 باید در نظر داشته باشید؟ توسط Coogan Brennan 5 دسامبر 2020 ارسال شده در 5 دسامبر 2020

توجه: شما هنوز هم می توانید در شبکه Ethereum 2.0 اعتبار سنج شوید! یک زمان انتظار برای فعال شدن به عنوان اعتبار سنج وجود دارد – از 4 دسامبر سال 2020 ، زمان انتظار تقریباً است 9.9 روز. مراحل موفقیت در قسمت 1 این مجموعه را مشاهده کنید.

1. سلب مسئولیت
2. معرفی
3. ملاحظات تنظیمات اعتبارسنج

1. سخت افزار اثبات آینده
2. برای اجرای یا عدم اجرای یک مشتری Eth1?
3. مجازی در مقابل میزبانی محلی
4. انتخاب مشتری Eth2 و جلوگیری از مجازات ها

تنظیم نمونه AWS

سیستم عامل

قیمت گذاری

ذخیره سازی

بنادر

کلیدهای SSH و راه اندازی Instance

نصب Teku

الزامات

باینری نصب کنید

کاربر غیر روت ایجاد کنید

سرویس systemd ایجاد کنید

راه اندازی

سلب مسئولیت

این پستی است که من به عنوان کارمند ConsenSys و کسی که قصد دارد در زنجیره چراغ های راهنما شرکت کند ، می نویسم. جمله قبلی به این معنی است که من محصولات ConsenSys را در اولویت قرار می دهم (محصولات ConsenSys معمولاً در کلاس برای Ethereum بهترین هستند و همچنین من به تیم های مهندسی دسترسی دارم که می توانند به من در پاسخگویی به سوالات و عیب یابی کمک کنند). جمله دوم به این معنی است که من برای هزینه و سهولت استفاده در حال بهینه سازی هستم: من هزاران ETH ندارم که بتوانم پاداش قابل توجهی کسب کنم ، بنابراین برخی از میانبرها را دنبال می کنم. اینها تصمیماتی است که من برای اتخاذ تصمیم در Ethereum 2.0 گرفته ام تا آنجا که ممکن است ساده و قابل دسترسی برای افراد باشد ، اما با عواملی برای عدم تمرکز و حفظ حریم خصوصی همراه است. با این حال ، می توانید سیر گسترده آموزش زیر را دنبال کنید و گزینه های مختلفی را انتخاب کنید. در واقع ، اگر می توانید این کار را انجام دهید ، من شما را تشویق می کنم! 

آخرین ، مشارکت در Ethereum 2.0 بسیار آزمایشی است و شامل تعهد طولانی مدت است (من سه سال اختصاص می دهم). لطفاً درصورتی که هنوز در حال پیشرفت نیستید ، درصورت داشتن ریسک پذیری در سطح بالا راحت نیستید ، در آن شرکت نکنید. اگر درباره اینکه آیا باید شرط بندی کنید مطمئن نیستید ، لطفاً به انجمن بپیوندید اختلاف نظر ConsenSys و در کانال # teku-public بپرسید. 

معرفی

در پست قبلی ، ما در مورد دلایل استقرار Ethereum 2.0 بحث کردیم و 32 ETH را در قرارداد سپرده اصلی شبکه Ethereum 1.0 بررسی کردیم. ما در مورد تولید کلید و چگونگی روند بازی کردن صحبت کردیم صفحه لانچ Ethereum 1.0 را به 2.0 پیوند می دهد.

در 23 نوامبر ، حداقل مقدار ETH برای راه اندازی Ethereum 2.0 – حدود 524،288 – برآورده شد. افراد می توانند در قرارداد مشارکت داشته باشند و تعداد اعتبارسنجان از 4 دسامبر به بیش از 33000 نفر رسیده است.

آرون دیویس MetaMask نظرات خود را در کانال داخلی Stenning ConsenSys Slack به اشتراک می گذارد 

گرچه ورود به بلوک جنسیس به عنوان اعتبار سنج بسیار هیجان انگیز بود ، ثانیه هایی بعد من تجربه مشابهی با همکارم آرون دیویس در کانال داخلی ConsenSys داشتیم: برای چه کار دیوانه ای ثبت نام کردم؟ خوشبختانه ، من به افراد فوق العاده درخشان و فنی خیریه دسترسی کافی دارم تا به این rube برخی نکات ، اشاره ها و بینش در مورد اجرای زیرساخت های staking بدهم. امیدوارم بخشی از این توصیه ارزشمند را در اینجا به سایر علاقه مندان منتقل کنم.

این قسمت اول این مقاله خواهد بود: مواردی که باید هنگام انتخاب سخت افزار و نرم افزار برای اجرای کلاینت اعتبارسنج Ethereum 2.0 در نظر داشته باشید ، چیست؟ قسمت دوم از طریق ترکیب سخت افزار / نرم افزار خاصی که من برای مشتری اعتبار سنجی خود انتخاب کرده ام ، بررسی می شود. انتخاب هایی که برای پیکربندی خود انجام می دهید به منابع ، تمایل شخصی و ظرفیت فنی شما بستگی دارد. من تمام تلاشم را می کنم تا مشخص کنم که تعصبات و شرایط شخصی چگونه به انتخاب های من اطلاع می دهند.

آخر اینکه ، قبل از اینکه به آن بپردازیم ، می خواهم دوباره تکرار کنم که این پست ها تقریباً مانند ورودی های مجله برای تجربه من در تهیه 32 ETH (البته ورودی های ژورنالی با جنبه های فنی گسترده) است. به همین ترتیب ، ممکن است با پیشرفت زنجیره چراغ ، رویکرد خود را کمی تغییر دهم. به عنوان مثال ، من فکر کردم که قطعاً از AWS استفاده خواهم کرد. همانطور که در زیر خواهید خواند ، من در حال بررسی مجدد آن هستم. من همچنین در مورد عنصر مالی شرط بندی بسیار روشن خواهم گفت. Staking راهی برای حمایت از اکوسیستم Ethereum است ، اما برای استفاده عمومی پایدار ، برای افرادی که ETH را انجام می دهند نیز باید در دسترس و امکان پذیر باشد. 

سخت افزار اثبات آینده

الزامات اساسی برای راه اندازی اعتبار سنج امروزه به راحتی برآورده می شود. مارا اشمیت و کالین میرز راهنمای اعتبار سنجی on Bankless دارای حداقل نیازهای کافی است. چالش برانگیزترین جنبه برای تعیین تجهیزات اعتبارسنج Ethereum 2.0 متعادل سازی نیازهای فعلی Beacon Chain Phase 0 با هرگونه تقاضای فعلی ناشناخته آینده با ادامه توسعه است. (اگر شما راحت مراقب اعتبار سنج خود باشید و بتوانید به سرعت و به راحتی تغییرات را برطرف کنید ، این نگرانی نیست) 

بن Edgington ، مدیر پروژه Teku و ناشر Eth2.news, موارد لبه ای را در اختیار من قرار داد که ممکن است شبکه از مشتری اعتبار سنجی بیشتری طلب کند. کوتاه مدت ، بزرگترین نگرانی چیزی شبیه به این است حادثه سرور زمان Medalla, که در آن یک اشکال و رفع مشکل بعدی در مشتری Prysm نهایی شدن آزمایش را متوقف کرد (به طور خلاصه ، شبکه نمی تواند “بلوک تولید کند”). از آنجا که در شبکه نهایی نبود (هیچ “بلوک تأیید شده ای”) ، اعتبارسنج ها مجبور بودند تراکنش های بیشتری نسبت به حالت عادی در RAM خود داشته باشند. 

ماشین آلات با 8 گیگابایت RAM – که در شرایط عادی بیش از اندازه کافی بودند – با مشکلات “خارج از حافظه” مواجه شدند که ممکن است منجر به بریده شدن شود. یک سنبله مانند این ، گرچه غیر معمول است ، اما برای شبکه اصلی فاز 0 دور از ذهن نیست.

ابهامات پیکربندی آینده برای شبکه ادغام Ethereum 1.0 و 2.0 و معرفی sharding است. ما هنوز نمی دانیم چه زمانی این ادغام ها اتفاق می افتد یا دقیقاً به چه مواردی نیاز دارند. من می خواهم یک ستون فقرات پردازنده قوی وارد فاز 0 (4 هسته مجازی ، 16 گیگابایت RAM با 100 گیگابایت SSD) و سپس توجه خود را برای تنظیمات آینده در فضای ذخیره سازی متمرکز کنم (اتاق wiggle را اینجا بگذارید). لطفاً توجه داشته باشید که ممکن است این کار بیش از حد مجاز باشد و جوایز زیادی را متحمل شود.

اینها “ناشناخته های شناخته شده” در آینده هستند ، بیایید در مورد نکات اصلی تصمیم برای پیکربندی اعتبارسنجان امروز بحث کنیم.

برای اجرای یا عدم اجرای سرویس گیرنده Eth1?

این یک آداب و رسوم است که سعی می کنم دانش آموزان bootcamp ما را هرچه بیشتر تحت فشار قرار دهم: همگام سازی سرویس گیرنده Ethereum 1.0. این یک راز آشکار است که در واقع میزبانی گره “کامل” Ethereum 1.0 یک عمل عاشقانه است تا یک راه حل سخت گیرانه زندانی. “کامل” را باید نقل قول کرد زیرا حتی توسعه دهندگان هسته Ethereum نیز زمان سختی دارند که در مورد تعریف “گره کامل” به معنای واقعی توافق می کنند.

چیزی که همه می توانیم در مورد آن توافق کنیم: همگام سازی سرویس گیرنده Ethereum 1.0 بیش از آنچه تصور می کنید زمان و فضای بیشتری صرف می کند. اعتبارسنجان ما باید روشی برای سerال از پایگاه داده شبکه Ethereum 1.0 داشته باشند (کمی بعد دلیل آن را بررسی خواهیم کرد). اگر می خواهید فضا و سردرد همگام سازی را به صورت محلی ذخیره کنید ، می توانید از نقطه پایانی Infura استفاده کنید, که با ثبت نام بصورت رایگان در دسترس است. 

حتی اگر این امر موجب صرفه جویی قابل توجهی در ذخیره سازی و نگرانی های لجستیکی می شود ، مقدار مشخصی از تمرکز زدایی را به طور همزمان برای شبکه های Eth1 و Eth2 فدا می کند. اگر Infura پایین می آمد, که بسیار نادر است اما رخ می دهد, که باعث ایجاد یک اثر موج دار در سراسر اعتبارسنجان Ethereum 2.0 می شود و از آن برای نقطه پایانی Ethereum 1.0 استفاده می کنند. چیزی که باید در نظر گرفت!

(فقط باید روشن شود: دشواری همگام سازی یک گره کامل Ethereum مربوط به ماهیت دولت جهانی Ethereum است ، نه با توسعه دهندگان هسته ای Ethereum 1.0 که کار شگفت انگیزی برای مقابله با این مشکل فوق العاده چالش برانگیز انجام داده اند.)

میزبانی مجازی و محلی

مورد بعدی برای من میزبانی یک گره اعتبار سنج به صورت محلی (در خانه من) یا به طور مجازی (در یک ارائه دهنده خدمات مجازی مانند Amazon Web Services (AWS) ، Digital Ocean و غیره) بود. همانطور که در قسمت قبلی اشاره کردم ، من به خودم اعتماد ندارم که یک گره اعتبارسنج ثابت از خانه اجرا کنم ، حتی روی یک لپ تاپ قدیمی که در جایی ذخیره نشده است. دست و پا چلفتی و احمقانه ، من یا آن را لگد می زدم یا فراموشش می کردم.

من ترجیح می دهم گره خود را بر روی AWS اجرا کنم زیرا این چیزی است که بیشتر با آن آشنا هستم (با این حال ، بعد از گذراندن این مراحل ، حدس می زنم این تصمیم را بگیرم. بعداً در مورد این بحث خواهم کرد). معامله در اینجا دوباره عدم تمرکز است: اگر AWS کاهش یابد یا مشکلی داشته باشد (مثل همین اخیرا) ، من در رحمت آنها هستم. اگر تعداد کافی از افراد گره های AWS را اجرا کنند ، می تواند بر شبکه بزرگتر Ethereum تأثیر بگذارد.

افراد احتمالاً خود را برای این مورد انتخاب می کنند. میزبانی محلی نوع خاصی از پروژه است و همه افراد زمان ، منابع یا تعهد لازم را ندارند. در حالی که میزبانی مجازی یک نیروی متمرکز است ، من بخاطر سهولت استفاده و (امیدوارم) تضمین شده بودن آن ، تصمیم به استفاده از آن بگیرم. 

اگر می خواهید یک گره اعتبار سنج به صورت محلی اجرا کنید ، هنوز هم می توانید جهت کلی این آموزش را دنبال کنید, سری آموزشهای عالی Somer Esat با مشتریان مختلف یا حتی یک Raspberry Pi Model 4B با 8 گیگابایت RAM با Ethereum در ARM همگام سازی کنید. (همگام سازی در Raspberry Pi هنوز بسیار آزمایشی است و افراد باید منتظر بمانند تا Ethereum در تیم ARM ثبات خود را تأیید کند)

انتخاب مشتری Eth2 و جلوگیری از مجازات ها

یکی دیگر از گزینه های اصلی ، مشتری Ethereum 2.0 در میان مشتریان موجود است: فانوس دریایی, لودستار, نیمبوس, پرایسم و تکو. من به شدت نسبت به تکو تعصب دارم و به اندازه کافی زرنگ نیستم که بتوانم درمورد نکات دقیق مشتری بحث کنم. این مقاله یک نمای کلی از عملکرد مشتری در Medalla است. (به خاطر داشته باشید که Medalla از پردازنده ها بیش از خواسته اصلی خواستار شده است.)

Proof of Stake انگیزه های آشکاری را برای تشویق رفتار صحیح در شبکه در بر می گیرد. اینها به صورت آفلاین بودن اعتبارسنجها و حرکت چشمگیر بازیگران برای اقدام مخرب علیه شبکه ، آگاهانه یا غیر از این ، صورت می گیرد..

رایج ترین مسئله این است که اطمینان حاصل کنید اعتبار سنجی شما در دسترس شبکه است. این به معنای اطمینان از آنلاین بودن اعتبار سنجی شماست. رویکرد DevOps برای این مسئله وجود دارد – ایجاد سیستم نظارت و هشدار برای اینکه در صورت آفلاین شدن اعتبار سنجی شما به شما هشدار دهد – که من در اینجا به آن نمی پردازم.

اما راه دیگری برای غیرقابل دسترس بودن در شبکه وجود دارد و آن این است که مشتری شما به یک دلیل یا دلیل دیگر شروع به بد رفتاری کند. بعد از اشکال سرور زمان باعث کندی شبکه در Medalla شد ، توسعه دهندگان هسته ای Eth2 گرد هم آمدند تا توسعه دهند “[a] قالب استاندارد برای انتقال سابقه امضای یک کلید به معتبران اجازه می دهد تا بدون خطر امضای پیام های متناقض ، به راحتی بین مشتری ها جابجا شوند.” همه مشتریان از این محافظت برخوردار نیستند ، اما Teku از این محافظت برخوردار است. در اینجا جایی است که می توانید در مورد استفاده از Teku’s Slash Protection (به طور پیش فرض اجرا می شود) از جمله مهاجرت بین گره های Teku یا گره غیر Teku به Teku بخوانید.

اگر با مشتری خود مشکلی دارید و باید کل شبکه را مجدداً راه اندازی کنید ، باید از ضعف ذهنی آگاه باشید. Proof of Work به هر کسی اجازه می دهد تا به بلوک پیدایش شبکه برگردد و با اعتماد به نفس حالت شبکه را از ابتدا ایجاد کند. با این حال ، Proof of Stake از این نظر قابل توجه است: اگر یک سوم اعتبار سنج های شبکه در یک نقطه خاص هنوز به امضای بلوک ها و تأیید ادامه دهند ، آنها می توانند وضعیت شبکه را تغییر دهند و آن داده های نادرست را به یک گره همگام سازی با اگر بازیگران مخرب گره همگام سازی را قبل از رسیدن گره همگام سازی به جایی که اعتبارسنج ها وجوه خود را برداشت می کنند ، شبکه کنند. در اینجا می توانید اطلاعات بیشتری در مورد آن بخوانید ، اما پاسخ کوتاه این است که شما باید یک “ایستگاه بازرسی موضوعیت ضعیف” یا یک پرونده حالت رمزگذاری شده داشته باشید ، اساساً بایگانی شبکه. تکو پرچم های شروع را برای هر دو فراهم می کند.

آخرین نگرانی در مورد پنالتی جدی ترین مسئله است: Slashing. Slashing زمانی اتفاق می افتد که staker بر خلاف قوانین شبکه کار کند. متفاوت از مجازات شدن با آفلاین بودن است. با ارسال اطلاعات اعتبارسنجی متناقض ، فعالانه علیه شبکه کار می کند. برای یادگیری بیشتر در مورد برش و چگونگی جلوگیری از آن ، مواد بسیار خوبی وجود دارد:

• پست جامع و پیشگیرانه Slashing پیشگیری Prysm.

• r / Ethstaker Moderator Superphiz’s Rules of Thumb for Slashing

• گفتگوی Superphiz با جیم مک دونالد از Attestant درباره Slashing

نکته اصلی این است که یک کلید اعتبار سنج را روی چندین مشتری اجرا نکنید. ظاهرا این همان چیزی است که باعث اولین رویداد قتل عام تاکنون شده است, که در تاریخ 2 دسامبر رخ داد. از آن زمان تعدادی قتل عام رخ داده است! اگر از یک نمونه به حالت دیگر مهاجرت می کنید ، چهار بار بررسی کنید که قرار نیست دو دستگاه از یک کلید کار کنند:

پاپا بن اینطور که هست بهش میگه. منبع

مشخصات پیکربندی اعتبار سنج AWS + Infura + Teku

راه اندازی بلوک Genesis من:

سیستم عامل: Ubuntu Server 20.04 LTS (HVM) (سرویس وب آمازون)

پردازنده: پردازنده Intel Xeon Platinum 8000 سری ، 3.1 گیگاهرتز. (سرویس وب آمازون)

حافظه: 4 هسته مجازی ، 16 گیگابایت RAM (سرویس وب آمازون)

ذخیره سازی: 100 گیگابایت SSD ، 300/3000 IOPS (سرویس وب آمازون)

مشتری Ethereum 1.0: نقطه پایانی Infura (ردیف رایگان)

مشتری Ethereum 2.0: تکو

با بررسی تمام ملاحظات بالا ، من از بهترین روش برای ایجاد یک تنظیم اعتبار سنج مطمئن نبودم. برای خودم ، من می خواهم دستگاهی را انتخاب کنم و به طور کلی حداقل دو سال نگران تغییر آن نیستم. این به هزینه اعتبارسنجی کلی کمک می کند (من می توانم از چند سال قفل شدن با یک ارائه دهنده مجازی تخفیف قابل توجهی بگیرم) و من در چرخش سرورها چابک نیستم. امیدوارم این رویکرد آینده نگری یا “بیش از حد” در طی دو سال آینده زندگی من را کمی آسان کند.

در ابتدا ، اطمینان داشتم AWS بهترین پلتفرم مجازی است و این سرویسی است که برای این پست و پست بعدی استفاده خواهم کرد. با این حال ، پس از گذراندن کل مراحل ، متوجه شدم که AWS برای توسعه دهنده فردی بیش از حد مجاز است. به نظر می رسد قدرت واقعی AWS ظرفیت آن در مقیاس پویا برای پاسخگویی به تقاضا باشد که با هزینه حق بیمه همراه است. این برای یک پروژه در مقیاس بزرگ ، در سطح شرکت ، اما فردی Ethereum 2.0 منطقی است جاری نیاز مشتری به چنین سختگیری نیاز ندارد.

من قصد دارم به AWS ادامه دهم اما در عین حال گزینه اجرای نمونه ای را در Digital Ocean سرگرم می کنم ، که ممکن است برای یک توسعه دهنده خاص مناسب تر باشد. اطلاعات بیشتر در این مورد در تاریخ بعد.

حساب Infura را تنظیم کنید

من تصمیم دارم از Infura به عنوان نقطه پایانی Ethereum 1.0 استفاده کنم. در حال حاضر ، زنجیره چراغها در حال مشاهده قرارداد سپرده گذاری در Ethereum 1.0 برای فعال کردن استکرهای جدید است که 32 ETH را به درستی سپرده و امضای BLS مناسب را ارسال کرده اند.

در آینده ، زنجیره beacon با شروع استفاده از اطلاعات دولت از Ethereum 1.0 برای ایجاد ایست های بازرسی موازی روی زنجیره beacon ، آزمایش پردازش بیشتر را شروع می کند.

همانطور که در بالا ذکر کردیم ، دو روش اصلی برای قابلیت مشاهده برای شبکه Ethereum 1.0 وجود دارد. یکی همگام سازی و نگهداری فعال گره Ethereum 1.0 ، که یک پایگاه داده محلی حالت Ethereum 1.0 ایجاد می کند. مورد دیگر استفاده از سرویسی مانند Infura است که نقطه پایانی Ethereum 1.0 آسان را فراهم می کند ، از طریق HTTPS یا وب سوکت.

برای یک حساب کاربری در اینجا وارد شوید. پس از داشتن حساب ، روی آرم Ethereum در سمت چپ کلیک کنید.

روی «ایجاد پروژه جدید» در گوشه بالا سمت راست کلیک کنید

پروژه خود را نامگذاری کنید (پروژه من “Eth 2 Validator” است) ، و به “تنظیمات” بروید ، مطمئن شوید که نقاط پایانی شبکه “Mainnet” است و نقطه پایانی HTTPS را کپی کنید:

بعداً از این برای دستور راه اندازی سرویس گیرنده Teku خود استفاده خواهیم کرد!

تنظیم نمونه AWS

راه اندازی یک نمونه EC2 در آمازون مستقیم است. ما در اینجا و آنجا چند تغییر ایجاد خواهیم کرد تا به مثال مجازی ما کمک کند تا با Teku به خوبی بازی کند.

یک حساب AWS ایجاد کنید (متفاوت از حساب Amazon.com) و وارد کنسول AWS شوید. به صفحه EC2 بروید که ظاهری شبیه به این دارد:

روی دکمه “Launch Instance” کلیک کنید. سپس صفحه زیر را مشاهده خواهید کرد:

سیستم عامل

در اینجاست که ما می خواهیم از تصویر ماشین (که به نظر من یک سیستم عامل است) برای نمونه مجازی خود استفاده کنیم. من اوبونتو سرور 20.04 را انتخاب می کنم که یک محیط سرور مبتنی بر Linux است. محیط سرور اوبونتو دارای چند تفاوت کلیدی در بهینه سازی با محیط دسک تاپ اوبونتو است. تفاوت اصلی برای اهداف ما این است که سرور اوبونتو فاقد رابط کاربری گرافیکی (GUI) است. جایی که ما می رویم ، فقط یک خط فرمان وجود دارد! مرا به روزهای Apple II برگرداند.

پس از انتخاب سیستم عامل ، نوع نمونه خود را انتخاب می کنیم:

من این منو را بسیار طاقت فرسا می دانم ، بنابراین قصد دارم آن را برای شما کمی تجزیه کنم. در اینجا ما هسته رایانه / قدرت RAM / CPU را برای دستگاه خود انتخاب می کنیم. این “حافظه فعال” یا “حافظه فعال” دستگاه است و از حافظه (هارد دیسک) دستگاه جدا است. آن را به عنوان موتور نمونه مجازی خود در نظر بگیرید که سیستم عامل Ubuntu Server خود را بر روی آن اجرا خواهیم کرد. AWS این موارد را به خانواده های نمونه جداگانه ای نشان می دهد که با ستون انتهای سمت چپ با حرف / عدد مشخص می شوند.

خانواده های نمونه تنظیمات سخت افزاری متفاوتی دارند ، همانطور که موتورهای مختلف ماشین پیکربندی های مختلفی از پیستون ها ، دوشاخه ها و سوخت ها برای پاسخگویی به خواسته های مختلف دارند. ما به دو مورد از خانواده های “محاسبه عمومی” آنها یعنی m5 و t3 خواهیم پرداخت.

من نمونه m5.xlarge را انتخاب می کنم که 4 هسته رایانه مجازی (vCPU) و 16 گیگابایت RAM را فراهم می کند. بعد از حدود یک روز اجرای شبکه اصلی Ethereum 2.0 ، دستگاه من بیش از 4٪ از vCPU موجود استفاده نکرده است. همانطور که در بخش “آینده اثبات” در بالا ذکر شد ، تقاضای شبکه Ethereum 2.0 فقط افزایش خواهد یافت. اما برای چند ماه آینده ، بدون وجود افزایش عمده شبکه طولانی مدت ، من به احتمال زیاد با یک نمونه m5 خوب خواهم بود. بزرگ (2 هسته مجازی / vCPU ، 8 گیگابایت RAM)

افراد فنی باهوش تر از من نیز نمونه t3.large را به عنوان یک گزینه مناسب برای Ethereum 2.0 توصیه کرده اند. t3.large دارای 2 vCPU و 8 گیگابایت حافظه است ، مانند m5.large ، اما خانواده t3 برای فعالیتهای “قابل انفجار” شبکه (جهش در CPU) ساخته شده است نه خانواده m5 که برای بارهای مداوم پردازنده ساخته شده است..

قیمت گذاری

آخرین چیزی که قبل از شروع به ذخیره سازی باید به آن اشاره کنیم قیمت است. AWS در مقایسه با سایر گزینه ها مانند Digital Ocean گران است. شما هزینه CPU (خانواده نمونه خود) و فضای ذخیره سازی (هارد دیسک خود) را براساس آنچه استفاده می کنید جداگانه پرداخت می کنید. پردازنده به صورت ساعتی پرداخت می شود. از آنجا که اعتبار سنج ها باید 24 ساعت آنلاین باشند ، برای انجام محاسبات تقریبی می توانید از جدول قیمت زیر (از دسامبر 2020) استفاده کنید: 

اینها قیمتهای درخواستی است. AWS چیزی به نام را فراهم می کند رزرو شده در حالت نمونه, جایی که اگر قول دهید یک نمونه مجازی از یک سال به سه سال داشته باشید ، می توانید تا 50-60٪ کاهش هزینه در جدول قیمت فوق داشته باشید. (با تشکر از جیسون کرومن برای این نکته!)

از صفحه اصلی EC2 ، روی “موارد رزرو شده” در فهرست سمت چپ کلیک کنید ، که در زیر نشان داده شده است:

روی “نمونه موارد رزرو شده” کلیک کنید:

در منویی که ظاهر می شود ، جزئیات نوع نمونه و مدت زمان مورد نظر برای دیدن قیمت گذاری را وارد کنید (من m5.xlarge و مدت 36 ماه را انتخاب می کنم):

روی «جستجو» کلیک کنید و گزینه های قیمت را ببینید:

به اعتقاد من بیش از 50٪ تخفیف قابل توجهی در قیمت وجود دارد ، اما من سه سال در زندان هستم. پس از خرید Reservation Instance ، AWS سپس آن را روی جعبه مجازی موجود اعمال می کند یا پس از راه اندازی آن را اعمال می کند. به یاد داشته باشید این شامل فضای ذخیره سازی (هارد دیسک) نیست. 

توجه: من هنوز این کار را انجام نمی دهم ، زیرا هنوز متقاعد نشده ام که AWS بهترین گزینه برای یک فرد است که از یک تا سه گره اعتبارسنج Ethereum 2.0 استفاده می کند. من نمونه ای را با قیمت گذاری درخواستی اجرا می کنم تا ببینم قبل از تعهد چگونه پیش می رود. 

ذخیره سازی

با بازگشت به روند راه اندازی نمونه ، در حال انتقال به برگه “افزودن فضای ذخیره سازی” هستیم

افراد درخشان فنی که با آنها مشورت کردم مقدار ذخیره سازی 100 گیگابایت SSD با هدف عمومی را توصیه کردند. فضای ذخیره سازی معمولاً گلوگاهی برای مشتریان Eth2 نیست. با این حال ، این است بدون در حال اجرا کردن یک مشتری Eth1 کامل. برای ذخیره سازی Eth1 ، یک برآورد محافظه کارانه حدود 1 ترابایت است. اگر از Infura استفاده نمی کنید حتماً این را حساب کنید.

من واحد موجود در ستون IOPS را در تصویر بالا نمی دانم ، اما این ورودی-خروجی برای هارد دیسک است که با پردازنده ارتباط برقرار می کند. این یک گلوگاه کلاسیک برای همگام سازی کامل گره Eth1 است. اگر به دنبال همگام سازی سرویس گیرنده کامل Eth1 در این دستگاه هستید و مشکلی دارید ، این می تواند مکانی برای جستجو باشد.

بنادر

با جستجوی “افزودن برچسب ها” ، به “پیکربندی گروه امنیتی” بروید. اینها دهانه های مختلفی است که برای انواع مختلف ارتباطات ورودی و خروجی با نمونه ایجاد شده است.

AWS به طور خودکار پورت SSH سنتی را باز می کند ، زیرا این اصلی ترین راه تعامل ما با نمونه است. سکه کاشو و Somer Esat’s راهنماهای عالی هر دو دسترسی رمز عبور را برای SSH غیرفعال می کنند ، اما وقتی نمونه را راه اندازی می کنیم می بینیم که گزینه پیش فرض برای AWS نیست. با این حال ، خوب است که پورت SSH خود را به عددی بین 1024-65535 تصادفی دهید. این امر برای جلوگیری از اسکن شبکه توسط پورت استاندارد SSH توسط بازیگران مخرب است. نحوه ایمن سازی پورت SSH خود را به طور کلی مشاهده کنید اینجا و به طور خاص برای AWS اینجا.

ما برای جای دادن مشتری Teku باید دو قانون امنیتی اضافه کنیم و این ارتباط با ارتباطات نظیر به نظیر است. شبکه های بلاکچین غیرمعمول هستند به این معنا که گره ها مستقیماً با یکدیگر صحبت می کنند. به جای مشاوره با یک گره مرکزی ، یک گره منفرد با “شایعه پردازی” با بسیاری از گره ها ، درک و فهم وضعیت شبکه را حفظ می کند. این بدان معناست که وقتی مشتری با مشتری دیگر دست می دهد ، اطلاعات مربوط به شبکه را مبادله می کنند. با گره های مختلف بار کافی انجام می شود ، اطلاعات در سراسر شبکه منتشر می شوند. در حال حاضر ، گره اعتبارسنج Eth2 من دارای 74 همتا است که با آنها چت می کند.

Teku با سایر گره های پورت 9000 ارتباط برقرار می کند ، بنابراین ما این مورد را برای UDP و TCP باز خواهیم کرد, دو نوع مختلف از پروتکل های ارتباطی. 

پس از آن ، باید چیزی شبیه به این باشد:

کلیدهای SSH و راه اندازی Instance

در آخر ، به “مرور و راه اندازی” بروید ، یک نمای کلی از انتخاب های انجام شده. پس از تأیید ، یک منوی بازشو در مورد کلیدهای SSH وجود دارد. من مال خود را نشان نمی دهم زیرا حاوی اطلاعات حساس است. یعنی ، کلید اصلی برای تأیید اعتبار و ورود به نمونه مجازی از طریق SSH (خط فرمان محلی) استفاده می شود. اگر قبلاً یک جفت ندارید ، AWS یکی برای شما ایجاد می کند. شما باید این را بارگیری کنید و مانند یک کلید خصوصی Ethereum با آن برخورد کنید! این تنها راه اتصال به نمونه شماست و AWS آن را برای شما ذخیره نمی کند.

وقتی همه چیز خسته کننده شد ، این پنجره ظاهر می شود:

باشه! با این کار ، بیایید به سراغ دسترسی و ایمن سازی نمونه خود برویم و سپس Teku را نصب و اجرا کنیم!

دسترسی به نمونه

راه اصلی دسترسی به نمونه AWS از طریق SSH است, “یک پروتکل رمزنگاری شده برای سرویس های شبکه عامل به طور ایمن از طریق یک شبکه بدون امنیت.” همانطور که قبلاً ذکر شد ، AWS به طور پیش فرض تأیید اعتبار رمز ورود را برای دسترسی به نمونه غیرفعال می کند. شما فقط می توانید از جفت کلید تولید شده قبل از راه اندازی نمونه استفاده کنید. صفحه کلید باید دارای پایان پرونده a.pem باشد. 

AWS یک روش تمیز برای دریافت دستور SSH شما فراهم می کند. با کلیک بر روی نمونه در حال اجرا از صفحه اصلی EC2 ، یک دکمه در سمت راست بالای صفحه وجود دارد که می گوید “اتصال”:

در صفحه بعدی یک دستور SSH مخصوص نمونه شما وجود دارد. ساختار آن به صورت زیر خواهد بود:

ssh -i "PATH_TO_AWS_KEYPAIR.pem" [ایمیل محافظت شده]_IDENTIFIER.compute-ZONE.amazonaws.com

ورود این دستور به یک ترمینال جلسه SSH را آغاز می کند. اولین بار ، دستگاه محلی از شما می پرسد که آیا می خواهید به اثر انگشت ECDSA ارائه شده توسط AWS اعتماد کنید. این برای جلوگیری از حمله مرد در وسط و در صورت نگرانی ، کاربر می تواند اثر انگشت نمونه خود را دنبال کند این مراحل.

در یک ترمینال جدا از جلسه فعلی SSH ، پرونده های اصلی اعتبار سنج مورد نیاز برای اجرای Teku را منتقل کنید. در پست قبلی وبلاگ ، ما با استفاده از 32 ETH و به دست آوردن کلیدهای اعتبار سنج برای Ethereum 2.0. در پایان ، این ساختار پرونده برای ما باقی مانده است:

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

ما باید پرونده validator_key_info را به نمونه مجازی خود منتقل کنیم. پروتکل امن کپی (scp) به ما امکان می دهد این کار را ایمن انجام دهیم. با استفاده از مسیر دایرکتوری بالا و دستور قبلی SSH ، دستور عمومی scp زیر را متناسب کنید:

scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [ایمیل محافظت شده]_IDENTIFIER.compute-ZONE.amazonaws.com:~

(به “: ~” در انتهای کل دستور توجه داشته باشید.)

باید ببینید که یک انتقال فایل رخ می دهد. اگر دوباره به جلسه SSH خود بروید و ls را تایپ کنید ، باید فهرست منتقل شده را ببینید.

نصب Teku

اکنون که پرونده های اعتبارسنج مورد نیاز خود را داریم ، قصد داریم Teku را نصب کنیم. ابتدا باید برنامه های موجود را به روز کرده و سیستم های مورد نیاز جاوا را نصب کنیم:

جاوا را نصب کنید

به روز رسانی sudo apt && sudo apt install default-jre && sudo apt install default-jdk

جاوا دوبار نصب شده با موفقیت موفقیت آمیز بود:

جاوا – وارونگی

باینری را نصب کنید

آخرین نسخه پایدار Teku را اینجا پیدا کنید. آدرس پیوند را در پرونده tar.gz کپی کنید ، سپس از جلسه SSH خود ، آن را بارگیری کنید. نسخه من به این شکل است ، نسخه شما به احتمال زیاد متفاوت خواهد بود:

curl -JLO https://bintray.com/consensys/pegasys-repo/download_file؟file_path=teku-20.11.1.tar.gz

با دستور زیر فایل بارگیری شده را از حالت فشرده خارج کنید. اگر نسخه دیگری دارید ، نام آن پرونده را در مقابل teku-20.11.1.tar.gz قرار دهید:

tar -zxvf teku-20.11.1.tar.gz

برای تمیز کردن ، فایل tar.gz را حذف کنید.

بعد از تمام این مراحل ، فهرست خانه شما باید به این شکل باشد (شماره نسخه و محتوای Teku ممکن است متفاوت باشد:

ubuntu / └── teku-20.11.1 / ├── مجوز ├── bin / ├── lib / ├── مجوز-وابستگی. html ├── teku.autocomplete.sh └── validator_key_info / ├── فروشگاه کلید -M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

یک کاربر غیر روت ایجاد کنید

این مرحله از Somer Esat’s کپی شده است آموزش عالی اوبونتو / تکو

ما در حال ایجاد یک کاربر غیر ریشه به نام teku هستیم که می تواند Teku را کار کند. موارد زیر را وارد کنید:

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

ما همچنین می خواهیم یک فهرست داده سفارشی برای Teku ایجاد کنیم ، سپس به کاربر Teku اجازه دسترسی به آن را می دهیم:

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

سرویس systemd ایجاد کنید

این مرحله از Somer Esat’s اقتباس شده است آموزش عالی اوبونتو / تکو

این مرحله خدمتی را ایجاد می کند که Teku را در پس زمینه اجرا می کند. همچنین اگر به دلایلی متوقف شود ، این دستگاه به شما اجازه می دهد سرویس به طور خودکار مجدداً راه اندازی شود. این یک مرحله ضروری برای اطمینان از اعتبار سنجی 24-7 است.

با استفاده از ویرایشگر متن nano فایل سرویس را ایجاد کنید:

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

در این فایل (که باید خالی باشد) ، ما می خواهیم مجموعه ای از دستورات را برای سیستم در هنگام شروع سرویس قرار دهیم. این کد زیر است ، شما باید موارد زیر را که در طول این سفر جمع آوری کرده ایم را در زیر وارد کنید:

• Infura Eth1 HTTP Endpoint
• مسیر دایرکتوری validator_key_info با دو فایل مربوط به کلید معتبر
• مسیر داده های سفارشی (lib / var / teku)

این مقادیر را در کد bold زیر قرار داده و سپس همه آنها را در ویرایشگر متن nano کپی کنید:

[واحد] توضیحات = گره Teku Beacon Wants = network-online.target After = network-online.target [سرویس] نوع = ساده کاربر = teku گروه = teku راه اندازی مجدد = همیشه RestartSec = 5 ExecStart = / home / ubuntu / teku-20.11 .1 / bin / teku – شبکه = شبکه اصلی –eth1-endpoint = INFURA_ETH1_HTTP_ENDPOINT_GOES_HERE – اعتبار سنج-کلیدها = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json: /home/ubuntu/validator_key_info/validator_keys_txt_CD78_START_64_VID_7 –rest-api-enabled = true –rest-api-docs-enabled = true – metrics-enabled –validators-keystore-locking-enabled = false –data-base-path = / var / lib / teku [نصب] WantedBy = multi-user.target

دستور-X را تایپ کنید ، سپس “Y” را تایپ کنید تا تغییرات خود را ذخیره کنید

برای به روزرسانی آن ، باید “systemctl” را دوباره راه اندازی کنیم:

sudo systemctl daemon-reload

شروع سرویس:

sudo systemctl شروع teku

بررسی کنید که آیا خوب شروع نشده است:

وضعیت sudo systemctl teku

اگر خطایی مشاهده کردید ، با اجرای جزئیات بیشتر:

sudo journalctl -f -u teku.service

با اجرای سرویس Teku می توانید متوقف شوید:

sudo systemctl stop teku

صفحه عیب یابی Teku را برای خطاهای رایج بررسی کنید یا اختلاف تکو را بررسی کنید, که توسط تیم کنترل می شود.

پس از احساس اتمام کار ، در صورت خاموش شدن سرویس ، سرویس را فعال کنید:

sudo systemctl Teku را فعال می کند

شما آن را دارید! همه چیز باید در حال حاضر در حال پخت و پز باشد. هنگام بازرسی از سرویس Teku ، یک سری سیاهههای مربوط به رویداد همگام سازی مشاهده خواهید کرد ، این اعتبار سنجی شما است که زنجیره چراغ را همگام سازی می کند. هنگامی که به سر رسید ، این گزارش ها به خواندن رویداد اسلات تغییر می کنند ، و همچنین عملکرد تأیید خود را مشاهده می کنید و پیشنهادات را مسدود می کنید.

راه اندازی

منبع: Beaconcha.in

در تاریخ 1 دسامبر در ساعت 12 بعد از ظهر UTC ، اولین بلوک های Beacon Chain تأیید شد. اولین بلوک از آنجا آمد اعتبارسنج 19026, با نقاشی های دیواری معمایی ، “آقای F اینجا بود.” دوازده ثانیه بعد بلوک بعدی آمد ، نقاشی های دیواری نشان می دهد که اعتبار سنج ممکن است در آن قرار داشته باشد زوگ ، سوئیس. Eth2 Beacon Chain به طور پیوسته رشد می کند ، هر 12 ثانیه بلوک به بلوک. سپس مانع بعدی پیش آمد: آیا اعتبارسنجان به اندازه کافی آنلاین هستند تا اولین دوره را نهایی کنند؟ آره! 82.27٪ از اعتبارسنجان ، صحت Epoch 0 ، طبقه هم ضرب المثل زنجیره Beacon را تأیید کردند. می توانید اطلاعات بیشتر در مورد پرتاب Beacon Chain و موارد بعدی را در اینجا بخوانید. 

منبع: Beaconcha.in

ما اکنون در Epoch 760 هستیم ، این بدان معناست که Beacon Chain تقریباً یک هفته است که روان کار می کند. 

در اینجا یک عکس از دیدگاه من از لحظه پیدایش است ، با استفاده از تنظیمات توصیف شده در این پست:

در قسمت بعدی ، خلاصه ای از اوضاع پیش خواهیم رفت. من می خواهم به معیارهای تکو دسترسی پیدا کنم ، در مورد هزینه اجرای AWS بحث کنم و به طور خلاصه در مورد وضعیت شبکه بحث کنم.

گوش به زنگ باشید!

منابع و پیوندها

با تشکر از جیمز بک ، مردیت باکستر ، جیسون کرومن ، آرون دیویس ، چامیندا دیویوتوتاولا ، بن ادینگتون ، The Dark Jester ، سامر عصات ، جوزف لوبین ، کالین میرز ، نیک نلسون ، مارا اشمیت ، آدریان ساتون و الکس تودوراچ برای پشتیبانی و کمک فنی.

برای جدیدترین اخبار Ethereum ، راه حل های سازمانی ، منابع توسعه دهنده و موارد دیگر ، در خبرنامه ما مشترک شوید. آدرس ایمیل