Ethereum 2.0’da Doğrulayıcı Olma Yolculuğum, Bölüm 2

blog 1HaberlerGeliştiricilerEnterpriseBlockchain AçıklamasıEtkinlikler ve KonferanslarBasınBültenler

Haber bültenimize abone ol.

E

Senin gizliliğine saygı duyuyoruz

Ana SayfaBlogGeliştiriciler

Ethereum 2.0’da Doğrulayıcı Olma Yolculuğum, Bölüm 2

Ethereum 2.0 doğrulayıcı istemcisi çalıştırmak için donanım ve yazılım seçerken göz önünde bulundurmanız gereken şeyler nelerdir? By Coogan BrennanAralık 5, 2020Yayınlandı Aralık 5, 2020

Ethereum'da Doğrulayıcı Olma Yolculuğum 2 0 Bölüm 2

Not: Ethereum 2.0 ağında hala bir doğrulayıcı olabilirsiniz! Doğrulayıcı olarak etkinleştirilecek bir bekleme süresi olacak – 4 Aralık 2020 itibarıyla bekleme süresi kabaca 9.9 günler. Bu serinin 1. Bölümündeki stake etme adımlarına bakın.

  1. Feragatname
  2. Giriş
  3. Doğrulayıcı Yapılandırmasında Dikkat Edilmesi Gerekenler
  1. Gelecek Prova Donanımı
  2. Eth1 İstemcisini Çalıştırmak veya Çalıştırmamak?
  3. Sanal ve Yerel Barındırma
  4. Eth2 Müşteri Seçimi ve Cezalardan Kaçınma
  • AWS örneğini kurma
    1. İşletim sistemi
    2. Fiyatlandırma
    3. Depolama
    4. Portlar
    5. SSH Anahtarları ve Örnek Başlatma
    6. Teku’yu Kurmak
      1. Gereksinimler
      2. İkili yükle
      3. Root olmayan kullanıcı oluştur
      4. Systemd hizmeti oluştur
      5. Başlatmak
      6. Feragatname

        Bu, bir ConsenSys çalışanı olarak yazdığım ve işaret zinciri üzerinde pay sahibi olmayı planlayan biri olarak yazdığım bir gönderi. İlk ifade, ConsenSys ürünlerine öncelik verdiğim anlamına geliyor (ConsenSys ürünleri genellikle Ethereum için sınıfının en iyisidir ve ayrıca soruları yanıtlamama ve sorunları gidermeme yardımcı olabilecek mühendislik ekiplerine erişimim var). İkinci ifade, maliyet ve kullanım kolaylığı için optimize ettiğim anlamına geliyor: Önemli ödüller verecek binlerce ETH’ye sahip değilim, bu yüzden bazı kısayolları kullanıyorum. Bunlar, Ethereum 2.0’ı mümkün olduğunca basit ve bireyler için erişilebilir kılmak için aldığım kararlar, ancak ademi merkeziyetçilik ve mahremiyet için ödünleşimlerle birlikte geliyor. Bununla birlikte, aşağıdaki öğreticinin genel hatlarını takip edebilir ve farklı seçimler yapabilirsiniz. Aslında, eğer bunu yapabilirseniz, sizi teşvik ederim.! 

        Son olarak, Ethereum 2.0’da stake etmek oldukça deneyseldir ve uzun vadeli taahhüt gerektirir (üç yıl ayırıyorum). Hala geliştirilmekte olan bir şeyle yüksek düzeyde risk görevlisi konusunda rahat değilseniz, lütfen katılmayın. Bahis oynamanız gerekip gerekmediğinden emin değilseniz, lütfen şuraya katılın: ConsenSys uyuşmazlığı ve # teku-public kanalında sorun. 

        Giriş

        Bir önceki yazıda, Ethereum 2.0’ın dağıtımının nedenlerini tartıştık ve Ethereum 1.0 mainnet Depozito Sözleşmesinde 32 ETH’yi belirledik. Anahtar oluşturmaya ve stake etme sürecinin nasıl devam ettiğine değindik. Başlatma paneli Ethereum 1.0’ı 2.0’a bağlar.

        23 Kasım’da, Ethereum 2.0’ı başlatmak için minimum stake edilmiş ETH miktarı (yaklaşık 524.288) karşılandı. Kişiler sözleşmede yer almaya devam edebilir ve onaylayıcıların sayısı 4 Aralık itibarıyla 33.000’in üzerine çıktı.

        MetaMask’tan Aaron Davis, dahili ConsenSys Slack stake etme kanalında düşüncelerini paylaşıyor 

        Doğrulayıcı olarak Genesis bloğuna dahil olmak son derece heyecan verici olsa da, saniyeler sonra dahili ConsenSys stake kanalımızda meslektaşım Aaron Davis’e benzer bir deneyim yaşadım: Hangi çılgın görev için kaydoldum? Neyse ki, bu rube’ye stake etme altyapısını çalıştırma hakkında bazı ipuçları, öneriler ve bilgiler verecek kadar hayırsever, inanılmaz derecede zeki ve teknik insanlara erişimim var. Buradaki değerli tavsiyenin bir kısmını diğer ilgili taraflara iletmeyi umuyorum..


        Bu makalenin ilk bölümü şudur: Ethereum 2.0 doğrulayıcı istemcisi çalıştırmak için donanım ve yazılım seçerken göz önünde bulundurmanız gereken bazı şeyler nelerdir? İkinci bölüm, doğrulayıcı istemcim için seçtiğim özel donanım / yazılım kombinasyonunu inceleyecek. Yapılandırmanız için yapacağınız seçimler kaynaklarınıza, kişisel eğiliminize ve teknik kapasitenize bağlı olacaktır. Kişisel önyargıların ve koşulların seçimlerimi nasıl etkilediğini vurgulamak için elimden geleni yapacağım.

        Son olarak, konuya girmeden önce, bu gönderilerin neredeyse 32 ETH’yi (kapsamlı teknik yanları olan günlük girişleri olsa da) staj yapma deneyimim için günlük girişleri gibi olduğunu tekrarlamak istiyorum. Bu nedenle, işaret zinciri ilerledikçe yaklaşımımı biraz değiştirebilirim. Örneğin, kesinlikle AWS kullanacağımı düşünmeye başladım. Aşağıda okuyacağınız gibi, şimdi bunu yeniden değerlendiriyorum. Ayrıca stake etmenin mali unsuru hakkında da çok net olacağım. Stake etme, Ethereum ekosistemini desteklemenin bir yoludur, ancak sürdürülebilir kamu kullanımı için, ETH’ye sahip olan kişiler için erişilebilir ve mümkün olmalıdır.. 

        Gelecek Prova Donanımı

        Bugün bir doğrulayıcı çalıştırmanın temel gereksinimlerini karşılamak nispeten kolaydır. Mara Schmiedt ve Collin Meyers ’ Doğrulayıcı Kılavuzu Bankless, minimum gereksinimlerin iyi bir özetine sahiptir. Ethereum 2.0 doğrulayıcı ekipmanı belirlemenin en zorlu yönü, Beacon Chain Phase 0’ın mevcut ihtiyaçlarını, geliştirme devam ederken gelecekteki bilinmeyen taleplerle dengelemektir. (Doğrulayıcınızı yakından takip etme konusunda rahatsanız ve değişiklikleri hızlı ve kolay bir şekilde ele alabiliyorsanız bu bir endişe kaynağı değildir) 

        Ben Edgington, Teku Proje Yöneticisi ve yayıncısı Eth2.news, ağın daha fazla doğrulayıcı istemcisi talep edebileceği bazı uç durumlar sağladı. Kısa vadede, en büyük endişe şöyle bir şey olurdu Medalla zaman sunucusu olayı, Prysm istemcisindeki bir hatanın ve ardından gelen düzeltmenin test ağındaki sonlandırmayı durdurduğu (kabaca konuşursak, ağ “blok üretemedi”). Ağda kesinlik olmadığından (“onaylanmış bloklar” yok), doğrulayıcıların RAM’lerinde normalden çok daha fazla işlem tutması gerekiyordu. 

        Normal koşullarda fazlasıyla yeterli olacak olan 8 GB RAM’e sahip makineler, kesintiye neden olabilecek “yetersiz bellek” sorunlarıyla karşılaşmaya başladı. Böyle bir artış, alışılmadık olsa da, Faz 0 ana ağı için söz konusu değildir..

        Ağ için gelecekteki yapılandırma belirsizlikleri, Ethereum 1.0 ve 2.0’ın birleştirilmesi ve parçalanmanın getirilmesidir. Bu birleşmelerin ne zaman gerçekleşeceğini veya tam olarak ne gerektireceğini hâlâ bilmiyoruz. Aşama 0’a giden güçlü bir CPU omurgasına sahip olmak (4 sanal çekirdek, 100 GB SSD ile 16 GB RAM) ve ardından dikkatimi depolama alanıyla ilgili gelecekteki ayarlamalara odaklamak (burada kıpır kıpır boşluk bırakarak) istiyorum. Lütfen bunun aşırıya kaçabileceğini ve stake etme ödüllerini tüketebileceğini unutmayın..

        Bunlar geleceğin “bilinen bilinmeyenleri”, şimdi doğrulayıcılar için ana yapılandırma karar noktalarını tartışalım..

        Bir Eth1 istemcisini Çalıştırmak veya Çalıştırmamak?

        Bootcamp öğrencilerimize mümkün olduğunca sık bir şekilde tabi tutmaya çalıştığım bir geçit töreni: bir Ethereum 1.0 istemcisini senkronize etmek. “Tam” bir Ethereum 1.0 düğümüne ev sahipliği yapmanın, sertleştirilmiş, Mahkumun İkilemi çözümünden ziyade bir sevgi eylemi olduğu açık bir sırdır. Ethereum çekirdek geliştiricileri bile, “tam düğüm” ün gerçekte ne anlama geldiğinin bir tanımı üzerinde anlaşmaya varmakta zorlandığından “Tam” tırnak içine alınmalıdır..

        Hepimizin hemfikir olabileceği bir şey var: Bir Ethereum 1.0 istemcisini senkronize etmek hayal edebileceğinizden daha fazla zaman ve depolama gerektirir. Doğrulayıcılarımızın Ethereum 1.0 ağ veritabanını sorgulamanın bir yolunu bulmaları gerekiyor (nedenini biraz sonra öğreneceğiz). Yerel olarak senkronizasyon alanından ve sıkıntısından tasarruf etmek istiyorsanız, bir Infura uç noktası kullanabilirsiniz., kayıt ile ücretsiz olarak kullanılabilir. 

        Bu, önemli depolama ve lojistik kaygılardan tasarruf etse de, aynı anda Eth1 ve Eth2 ağları için belirli bir miktar ademi merkeziyetçilikten ödün verir. Infura düşecek olsaydı, bu son derece nadirdir, ancak meydana gelir, bu, Ethereum 2.0 doğrulayıcılarında onu Ethereum 1.0 uç noktası için kullanan bir dalgalanma etkisine neden olur. Dikkate alınacak bir şey!

        (Açık olmak gerekirse: Bir Ethereum tam düğümünü senkronize etmenin zorluğu, bu son derece zorlu problemle başa çıkmak için harika bir iş çıkaran Ethereum 1.0 çekirdek geliştiricileriyle değil, Ethereum dünya durumunun doğasıyla ilgilidir.)

        Sanal vs Yerel Barındırma

        Benim için bir sonraki düşüncem, yerel olarak (evimde) veya sanal olarak (Amazon Web Services (AWS), Digital Ocean vb. Gibi sanal bir hizmet sağlayıcıda) bir doğrulayıcı düğümü barındırmaktı. Önceki parçada bahsettiğim gibi, uzakta bir yerde depolanan eski bir dizüstü bilgisayarda bile, evden tutarlı bir doğrulayıcı düğümü çalıştıracağım konusunda kendime güvenmiyorum. Beceriksiz ve aptal, ya tekmeleyebilirim ya da unuturdum.

        Düğümümü AWS’de çalıştırmayı seçiyorum çünkü en aşina olduğum şey bu (Ancak tüm bu süreci tamamladıktan sonra, bu kararı ikinci kez tahmin ediyorum. Bunu daha sonra tartışacağım). Buradaki değiş tokuş yine ademi merkeziyetçiliktir: AWS düşerse veya herhangi bir sorun varsa (son zamanlarda yaptığı gibi), Onların merhametine kaldım. AWS’de yeterince kişi düğüm çalıştırıyorsa, bu daha büyük Ethereum ağını etkileyebilir.

        İnsanlar muhtemelen bunu kendi kendilerine seçecekler. Yerel barındırma özel bir proje türüdür ve herkesin gerekli zamanı, kaynağı veya taahhüdü yoktur. Sanal barındırma merkezileştirici bir güç olsa da, kullanım kolaylığı ve (umarım) garantili çalışma süresi nedeniyle onunla gitmeyi tercih ediyorum. 

        Yerel olarak bir doğrulayıcı düğüm çalıştırmak istiyorsanız, bu eğiticinin genel yönünü yine de takip edebilirsiniz., Somer Esat’ın farklı müşterilerle oluşturduğu mükemmel eğitim serisi veya hatta bir Raspberry Pi Model 4B’yi 8 GB RAM ile ARM üzerinde Ethereum ile senkronize edin. (Raspberry Pi’de senkronizasyon hala çok deneyseldir ve insanlar, ARM ekibindeki Ethereum’un kararlılığını onaylayana kadar beklemelidir)

        Eth2 Müşteri Seçimi ve Cezalardan Kaçınma

        Diğer bir önemli seçenek, mevcut müşteriler arasında Ethereum 2.0 istemcisidir: Deniz feneri, Lodestar, Nimbus, Prysm ve Teku. Teku’ya karşı çok önyargılıyım ve müşterilerin ince noktalarını tartışacak kadar anlayışlı değilim. Bu makale Medalla’daki müşteri performansına iyi bir genel bakış. (Medalla’nın işlemcilerden ana ağdan çok daha fazlasını talep ettiğini unutmayın.)

        Proof of Stake, ağda doğru davranışı teşvik etmek için açık caydırıcı unsurlar içerir. Bunlar, çevrimdışı olmak için doğrulayıcılar ve ağa karşı bilerek veya başka şekilde kötü niyetli eylemlerde bulunmak için aktörlerin daha dramatik bir hamlesi şeklini alır..

        En yaygın sorun, doğrulayıcınızın ağda kullanılabilir olduğundan emin olmaktır. Bu, doğrulayıcınızın çevrimiçi olduğundan emin olmanız anlamına gelir. Bu soruna DevOps yaklaşımı var: Doğrulayıcınız çevrimdışı olursa sizi uyaracak izleme ve uyarı sistemi oluşturma – burada ele almayacağım.

        Ancak ağda kullanılamamanın başka bir yolu vardır ve bu, istemcinizin bir nedenden ötürü yanlış davranmaya başlamasıdır. Sonra zaman sunucusu hatası Medalla’da ağ yavaşlamasına neden oldu, Eth2 çekirdek geliştiricileri geliştirmek için bir araya geldi “[A] Bir anahtarın imzalama geçmişini aktarmaya yönelik standart biçim, doğrulayıcıların çakışan iletileri imzalama riski olmadan istemciler arasında kolayca geçiş yapmasına olanak tanır.” Tüm müşteriler bu korumaya sahip değildir, ancak Teku’da vardır. Teku düğümleri arasında veya Teku olmayan bir düğümden Teku düğümüne geçiş dahil olmak üzere Teku’nun Eğik Çizgi Korumasını (varsayılan olarak çalışır) kullanma hakkında bilgi edinebileceğiniz yer burasıdır..

        İstemcinizle sorun yaşıyorsanız ve tüm ağı yeniden başlatmanız gerekiyorsa, Zayıf Öznelliğin farkında olmanız gerekir. Proof of Work, herkesin ağın başlangıç ​​bloğuna geri dönmesine ve ağ durumunu sıfırdan güvenmeden inşa etmesine izin verir. Bununla birlikte, Proof of Stake, bu konuda bir yakalamaya sahiptir: Belirli bir noktadaki ağ doğrulayıcılarının üçte biri, blokları ve doğrulamayı imzalamaya devam ederse, ağ durumunu değiştirebilir ve bu yanlış verileri, ağ, eğer kötü niyetli kişiler, senkronizasyon düğümü doğrulayıcıların fonlarını çektikleri yere ulaşmadan önce senkronizasyon düğümünü yakalarsa. Bununla ilgili daha fazlasını buradan okuyabilirsiniz, ancak kısa cevap, bir “zayıf öznellik kontrol noktasına” veya şifreli bir durum dosyasına, esasen ağın bir arşivine sahip olmanız gerektiğidir. Teku, her ikisi için de başlangıç ​​bayrakları sağlar.

        Son ceza endişesi en ciddi olanıdır: Kesmek. Eğik çizgi, bir staker ağın kurallarına aykırı çalıştığında meydana gelir. Çevrimdışı olmaktan cezalandırılmaktan farklıdır. Çakışan doğrulayıcı bilgileri göndererek aktif olarak ağa karşı çalışıyor. Kesmek ve nasıl önleneceğini öğrenmek için gerçekten harika materyaller var:

        Ana çıkarım, birden çok istemcide tek bir doğrulama anahtarı çalıştırmamaktır. Görünüşe göre bu şimdiye kadarki ilk slashing olayına neden oldu., 2 Aralık’ta meydana gelen. O zamandan beri çok sayıda kesme yapıldı! Bir örnekten diğerine geçiş yapıyorsanız, aynı anahtardan çalışan iki makinenizin olmayacağını dört kez kontrol edin:

        Papa Ben olduğu gibi söylüyor. Kaynak

        AWS + Infura + Teku Doğrulayıcı Yapılandırma Özellikleri

        Genesis blok kurulumum:

        İşletim sistemi: Ubuntu Sunucusu 20.04 LTS (HVM) (Amazon Web Hizmeti)

        İşlemci: Intel Xeon Platinum 8000 serisi işlemci, 3.1 GHz. (Amazon Web Hizmeti)

        Hafıza: 4 sanal çekirdek, 16 GB RAM (Amazon Web Service)

        Depolama: 100 GB SSD, 300/3000 IOPS (Amazon Web Hizmeti)

        Ethereum 1.0 istemcisi: Infura uç noktası (ücretsiz kullanım)

        Ethereum 2.0 istemcisi: Teku

        Yukarıdaki tüm hususları gözden geçirdiğimde, bir doğrulayıcı kurulumu oluşturmak için en iyi yaklaşımın ne olduğundan emin değildim. Kendim için, bir makine seçmek isterim ve genellikle en az iki yıl boyunca onu değiştirmek konusunda endişelenmem. Bu, genel doğrulayıcı maliyetine yardımcı oluyor (birkaç yıl için bir sanal sağlayıcıya bağlanarak önemli bir indirim elde edebilirim) ve sunucuları döndürme konusunda özellikle çevik değilim. Bu geleceğe yönelik veya “aşırı spesifikasyon” yaklaşımı umarım önümüzdeki iki yıl içinde hayatımı biraz daha kolaylaştırır.

        Başlangıçta, AWS’nin en iyi sanal platform olduğuna ve bu gönderi ve sonraki gönderi için kullanacağım hizmet olduğundan emindim. Ancak, tüm süreçten geçtikten sonra, AWS’nin bireysel geliştirici için gereğinden fazla olabileceğini fark ettim. AWS’nin gerçek gücü, yüksek bir maliyetle gelen talebi karşılamak için dinamik olarak ölçeklendirme kapasitesi gibi görünüyor. Bu, büyük ölçekli, işletme düzeyinde bir proje için ekonomik mantıklı, ancak bireysel Ethereum 2.0 akım müşteri gereksinimleri böyle bir titizlik gerektirmez.

        AWS ile devam edeceğim ancak aynı zamanda, bireysel bir geliştirici için daha uygun olabilecek Digital Ocean üzerinde bir bulut sunucusu çalıştırma seçeneğini de eğlendiriyorum. Daha sonraki bir tarihte daha fazlası.

        Infura Hesabı Kur

        Infura’yı Ethereum 1.0 uç noktam olarak kullanmayı seçiyorum. Şimdilik, işaret zinciri, 32 ETH’yi uygun şekilde yatırıp uygun BLS imzalarını gönderdiklerinde yeni stakerları etkinleştirmek için Ethereum 1.0’daki Para Yatırma Sözleşmesini izliyor..

        Gelecekte, işaret zinciri, işaret zinciri üzerinde paralel kontrol noktaları oluşturmak için Ethereum 1.0’dan gelen durum bilgilerini kullanmaya başlayarak daha fazla işlemeyi test etmeye başlayacak..

        Yukarıda bahsettiğimiz gibi, Ethereum 1.0 ağını görmenin iki ana yolu vardır. Bunlardan biri, yerel bir Ethereum 1.0 durum veritabanı oluşturan bir Ethereum 1.0 düğümünü senkronize etmek ve aktif olarak sürdürmektir. Diğeri, HTTPS veya HTTPS aracılığıyla erişilebilen kolay bir Ethereum 1.0 uç noktası sağlayan Infura gibi bir hizmet kullanmaktır. WebSockets.

        Buradan bir hesap oluşturun. Bir hesabınız olduğunda, sol taraftaki Ethereum logosuna tıklayın.

        Sağ üst köşedeki “Yeni Proje Oluştur” u tıklayın

        Projenizi adlandırın (benimki “Eth 2 Doğrulayıcı”) ve “Ayarlar” a gidin, ağ uç noktalarınızın “Mainnet” olduğundan emin olun ve HTTPS uç noktasını kopyalayın:

        Bunu daha sonra Teku istemci başlatma komutumuz için kullanacağız!

        AWS örneğini kurma

        Amazon’da bir EC2 bulut sunucusu kurmak basittir. Sanal örneğimizin Teku ile iyi oynamasına yardımcı olmak için burada ve orada birkaç ince ayar yapacağız.

        Bir AWS hesabı oluşturun (bir Amazon.com hesabından farklı) ve AWS Konsolunda oturum açın. Aşağıdaki gibi görünecek olan EC2 sayfasına gidin:

        “Örneği Başlat” düğmesini tıklayın. Daha sonra aşağıdaki ekranı göreceksiniz:

        İşletim sistemi

        Sanal örneğimizde (işletim sistemi olarak düşündüğüm) hangi makine görüntüsünü kullanmak istediğimizi seçtiğimiz yer burasıdır. Linux tabanlı bir Sunucu ortamı olan Ubuntu Server 20.04’ü seçiyorum. Ubuntu Sunucu ortamı, Ubuntu Masaüstü ortamından birkaç temel optimizasyon farkına sahiptir. Amaçlarımız açısından temel fark, Ubuntu Sunucusunda bir Grafik Kullanıcı Arayüzünün (GUI) olmamasıdır. Gittiğimiz yerde sadece bir komut satırı var! Beni Apple II günlerime geri getiriyor.

        İşletim sistemimizi seçtikten sonra, örnek tipimizi seçiyoruz:

        Bu menüyü oldukça yoğun buluyorum, bu yüzden sizin için biraz açıklayacağım. Burada, makinemiz için bilgi işlem çekirdeğini / RAM gücünü / CPU’yu seçiyoruz. Makinenin “ham” veya “etkin belleğidir” ve bir aygıtın depolamasından (sabit sürücü) ayrıdır. Ubuntu Sunucu işletim sistemimizi çalıştıracağımız sanal örneğimizin motoru olarak düşünün. AWS, bunları en soldaki sütunda harf / sayı kombinasyonu ile gösterilen ayrı bulut sunucusu ailelerine ayırır..

        Örnek aileleri, farklı araba motorlarının farklı talepleri karşılamak için farklı piston, tapa ve yakıt konfigürasyonlarına sahip olması gibi farklı donanım düzenlemelerine sahiptir. Onların “genel hesaplama” örnek ailelerinden ikisi olan m5 ve t3’e odaklanacağız.

        4 sanal bilgi işlem çekirdeği (vCPU’lar) ve 16 GB RAM sağlayan m5.xlarge örneğini seçiyorum. Ethereum 2.0 mainnet’i yaklaşık bir gün çalıştırdıktan sonra, makinem mevcut vCPU’nun% 4’ünden fazlasını kullanmadı. Yukarıdaki “Geleceğe Karşı Kanıtlama” bölümünde bahsedildiği gibi, Ethereum 2.0 ağ talepleri yalnızca artacaktır. Ancak önümüzdeki birkaç ay boyunca, herhangi bir uzun süreli büyük ağ artışları olmasaydı, büyük olasılıkla bir m5.large bulut sunucusu (2 sanal çekirdek / vCPU, 8 GB RAM) ile sorun yaşamazdım.

        Benden daha bilgili teknik insanlar da t3.large örneğini Ethereum 2.0 için makul bir seçenek olarak önerdiler. t3.large, m5.large ile aynı olan 2 vCPU ve 8 GB belleğe sahiptir, ancak t3 ailesi, tutarlı CPU yükleri için tasarlanmış m5 ailesinden çok daha “ani” ağ etkinliği (CPU’daki artışlar) için oluşturulmuştur..

        Fiyatlandırma

        Depolamaya geçmeden önce bahsetmemiz gereken son şey fiyattır. AWS, Digital Ocean gibi diğer seçeneklere kıyasla pahalıdır. Kullandığınız şeye bağlı olarak CPU (bulut sunucusu aileniz) ve depolama (sabit sürücünüz) için ayrı ayrı ödeme yaparsınız. CPU ücreti saatlik olarak ödenir. Doğrulayıcıların 24 saat çevrimiçi olması gerektiğinden, bazı kaba hesaplamalar yapmak için aşağıdaki fiyat tablosunu (Aralık 2020’den itibaren) kullanabilirsiniz: 

        Bunlar isteğe bağlı fiyatlardır. AWS, Rezerve Edilmiş Bulut Sunucusu fiyatlandırması, burada bir yıldan üç yıla kadar sanal bir örneğe sahip olacağınıza söz verirseniz, yukarıdaki fiyat tablosunda% 50-60’a varan maliyet indirimi elde edebilirsiniz. (Bu ipucu için Jason Chroman’a teşekkürler!)

        EC2 ana sayfasından, aşağıda gösterilen sol taraftaki menüden “Rezerve Edilmiş Bulut Sunucuları” nı tıklayın:

        “Ayrılmış Örneği Satın Al” ı tıklayın:

        Açılan menüde, örnek türü ayrıntılarını ve fiyatlandırmayı görmek istediğiniz süreyi girin (m5.xlarge ve 36 aylık bir dönem seçiyorum):

        “Ara” yı tıklayın ve fiyat seçeneklerini görün:

        % 50’nin üzerinde önemli bir fiyat indirimi var, inanıyorum ama üç yıldır kilitliyim. Rezerve Edilmiş Bulut Sunucusu satın aldığınızda, AWS bunu mevcut bir sanal kutuya uygular veya başlatıldığında uygular. Bunun depolama alanını (sabit sürücü) İÇERMEDİĞİNİ unutmayın. 

        Not: Bunu henüz yapmıyorum, çünkü AWS’nin bir ila üç Ethereum 2.0 doğrulama düğümünü tek tek stake etmek için en iyi seçenek olduğuna henüz ikna olmadığım için. Taahhüt etmeden önce nasıl gittiğini görmek için isteğe bağlı fiyatlandırmaya sahip bir örnek çalıştırıyorum. 

        Depolama

        Örnek başlatma sürecimize geri dönersek, “Depolama Ekleme” sekmesine geçiyoruz

        Danıştığım parlak teknik insanlar, 100 GB Genel Amaçlı SSD depolama miktarı önerdiler. Depolama, Eth2 istemcileri için genellikle bir darboğaz değildir. Ancak bu olmadan tam bir Eth1 istemcisi çalıştırmak. Eth1 depolaması için muhafazakar bir tahmin yaklaşık 1 TB olacaktır. Infura kullanmıyorsanız bunu hesaba kattığınızdan emin olun.

        Yukarıdaki resimde IOPS sütunundaki birimi bilmiyorum, ancak CPU ile iletişim kuran sabit sürücü için girdi-çıktı. Bu, tam Eth1 düğüm senkronizasyonu için klasik bir darboğazdır. Bu makinede tam bir Eth1 istemcisini senkronize etmek istiyorsanız ve sorun yaşıyorsanız, burası bakmanız gereken bir yer olabilir.

        Portlar

        “Etiket Ekle” yi atlayarak “Güvenlik Grubunu Yapılandır” seçeneğine ilerleyin. Bunlar, örnekle farklı türde gelen ve giden iletişim için oluşturulan farklı açıklıklardır..

        Bulut sunucusu ile etkileşim kuracağımız ana yol bu olduğundan, AWS otomatik olarak geleneksel SSH bağlantı noktasını açar. Sikke Kaju ve Somer Esat’s mükemmel kılavuzların her ikisi de SSH için şifre erişiminin devre dışı bırakılmasını önermektedir, ancak AWS için varsayılan seçenek olmayan örneği başlattığımızda göreceğiz. Ancak, SSH bağlantı noktanızı 1024-65535 arasında rasgele bir sayıya dönüştürmek iyi olur. Bu, kötü niyetli kişilerin standart SSH bağlantı noktasını ağda taramasını önlemek içindir. SSH bağlantı noktanızı genel olarak nasıl güvenli hale getireceğinizi görün İşte ve özellikle AWS için İşte.

        Teku istemcisini barındırmak için iki güvenlik kuralı eklemeliyiz ve bu eşler arası iletişimle ilgisi var. Blok zinciri ağları, düğümlerin doğrudan birbirleriyle iletişim kurması anlamında merkezden uzaklaştırılmıştır. Merkezi bir düğüme danışmak yerine, tek bir düğüm, birçok düğümle “dedikodu yaparak” ağ durumu hakkında bir anlayış geliştirecek ve sürdürecektir. Bu, bir müşteri diğeriyle anlaştığında, ağ hakkındaki bilgileri değiş tokuş edeceği anlamına gelir. Farklı düğümlerle yeterince kez yapıldığında, bilgi ağ boyunca yayılır. Şu anda, Eth2 Doğrulayıcı düğümümün sohbet ettiği 74 eşi var.

        Teku, 9000 bağlantı noktasındaki diğer düğümlerle iletişim kurar, bu nedenle bunu UDP ve TCP için açacağız, iki farklı tür iletişim protokolü. 

        Daha sonra şunun gibi görünmesi gerekir:

        SSH Anahtarları ve Örnek Başlatma

        Son olarak, yapılan seçimlere genel bir bakış olan “İncele ve Başlat” a gidin. Onaylandıktan sonra, SSH anahtarları hakkında bir açılır menü olacaktır. Hassas bilgiler içerdiği için benimkini göstermiyorum. Yani, anahtar çifti, SSH (yerel komut satırı) aracılığıyla sanal örneğin kimliğini doğrulamak ve bu örnekte oturum açmak için kullanılır. Halihazırda bir çiftiniz yoksa AWS sizin için bir tane oluşturur. Bunu indirmeli ve ona bir Ethereum özel anahtarı gibi davranmalısınız! Örneğinize bağlanmanın tek yolu budur ve AWS bunu sizin için kaydetmez.

        Her şey hunky-dory olduğunda, bu pencere görünecektir:

        Tamam! Bu bitti, şimdi örneğimize erişip güvenliğini sağladıktan sonra Teku’yu kurup çalıştıralım.!

        Örneğe Erişim

        AWS örneğine erişmenin ana yolu SSH’dir, “Ağ hizmetlerini güvenli olmayan bir ağ üzerinden güvenli bir şekilde çalıştırmak için bir şifreleme protokolü.” Daha önce belirtildiği gibi AWS, bulut sunucusuna erişim için parola kimlik doğrulamasını varsayılan olarak devre dışı bırakır. Yalnızca örnek başlatılmadan önce oluşturulan anahtar çiftini kullanabilirsiniz. Anahtar çiftinde biten bir .pem dosyası olmalıdır. 

        AWS, SSH komutunuzu almanın temiz bir yolunu sağlar. Ana EC2 sayfasından çalışan örneğe tıkladığınızda, sağ üstte “bağlan” yazan bir düğme vardır:

        Sonraki sayfada örneğinize özel bir SSH komutu olacaktır. Bu şekilde yapılandırılacak:

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [e-posta korumalı]_IDENTIFIER.compute-ZONE.amazonaws.com

        Bu komutu bir terminale girmek SSH oturumunu başlatır. Yerel makine ilk kez AWS tarafından sağlanan ECDSA parmak izine güvenmek isteyip istemediğinizi soracaktır. Bu, bir ortadaki adam saldırısı ve ilgilenirse, bir kullanıcı örneğinin parmak izini aşağıdaki şekilde alabilir: bu adımlar.

        Geçerli SSH oturumundan ayrı bir terminalde, Teku’yu çalıştırmak için gereken doğrulayıcı anahtar dosyalarını aktarın. Bir önceki blog gönderisinde, 32 ETH’yi stake etme ve Ethereum 2.0 için onaylayıcı anahtarlar edinme üzerinden yürüdük. Sonunda, bu dosya yapısıyla kaldık:

        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 dosyasını sanal örneğimize aktarmamız gerekiyor. Güvenli Kopyalama Protokolü (scp), bunu güvenli bir şekilde yapmamızı sağlar. Yukarıdaki dizine giden yolu ve önceki SSH komutunu kullanarak aşağıdaki genel scp komutunu uyarlayın:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [e-posta korumalı]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (Tüm komutun sonundaki “: ~” işaretine dikkat edin.)

        Bir dosya aktarımının gerçekleştiğini görmelisiniz. SSH oturumunuza geri dönüp ls yazarsanız, aktarılan dizini görmeniz gerekir..

        Teku’yu Kurmak

        Artık ihtiyacımız olan doğrulama dosyalarına sahip olduğumuza göre Teku’yu kuracağız. Öncelikle, mevcut programları güncellememiz ve gerekli Java sistemlerini yüklememiz gerekiyor:

        Java’yı yükleyin

        sudo apt güncellemesi && sudo apt install default-jre && sudo apt install default-jdk

        Yüklenen Java’nın başarılı olup olmadığını iki kez kontrol edin:

        java sürümü

        İkili Yükle

        En son kararlı Teku sürümünü burada bulun. Bağlantı adresini tar.gz dosyasına kopyalayın, ardından SSH oturumunuzdan indirin. Benimki şöyle görünüyordu, sizin sürümünüz büyük olasılıkla farklı olacak:

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

        İndirilen dosyayı aşağıdaki komutla açın. Farklı bir sürümünüz varsa, teku-20.11.1.tar.gz yerine o dosya adını girin:

        tar -zxvf teku-20.11.1.tar.gz

        Temizlik uğruna tar.gz dosyasını kaldırın.

        Tüm bu adımlardan sonra, ana dizininiz şöyle görünmelidir (Teku sürüm numarası ve içeriği farklı olabilir:

        ubuntu / └── teku-20.11.1 / ├── LİSANS ├── bin / ├── lib / ├── lisans-bağımlılığı.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

        Root olmayan bir kullanıcı oluşturun

        Bu adım Somer Esat’ın mükemmel Ubuntu / Teku öğreticisi

        Teku’yu çalıştırabilen teku adında root olmayan bir kullanıcı oluşturacağız. Aşağıdakileri yazın:

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

        Teku için de özel bir veri dizini oluşturacağız, ardından teku kullanıcısına ona erişim vereceğiz:

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

        Systemd hizmeti oluştur

        Bu adım Somer Esat’ın kitabından uyarlanmıştır. mükemmel Ubuntu / Teku öğreticisi

        Bu adım, Teku’yu arka planda çalıştıracak bir servis yapacaktır. Ayrıca, herhangi bir nedenle durursa, makinenin hizmeti otomatik olarak yeniden başlatmasına izin verecektir. Bu, doğrulayıcımızın 7 gün 24 saat çalıştığından emin olmak için gerekli bir adımdır.

        Nano metin düzenleyicisini kullanarak hizmet dosyasını oluşturun:

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

        Bu dosyaya (boş olması gerekir), systemd’nin hizmeti başlattığımızda yürütmesi için bir dizi komut koyacağız. İşte aşağıdaki kod, bu yolculuk boyunca topladığımız aşağıdaki öğelere katılmanız gerekecek:

        • Infura Eth1 HTTP Uç Noktası
        • validator_key_info, anahtarla ilgili iki geçerli dosya içeren dizin yolu
        • Özel veri yolu (lib / var / teku)

        Bu değerleri aşağıdaki kalın koda girin, ardından hepsini nano metin düzenleyicisine kopyalayın:

        [Birim] Açıklama = Teku İşaret Düğümü İstiyor = network-online.target Sonra = network-online.target [Servis] Tür = basit Kullanıcı = teku Grup = teku Yeniden Başlat = her zaman Yeniden Başlat = 5 Yürütme Başlangıcı = / home / ubuntu / teku-20.11 .1 / bin / teku –network = mainnet –eth1-endpoint = INFURA_ETH1_HTTP_ENDPOINT_GOES_HERE –validator-keys = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json: /home/ubuntu/validator_CD_xt.tinfo/validator_keys/KST89 –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-lock-enabled = false –veri tabanı yolu = / var / lib / teku [Yükle] WantedBy = multi-user.target

        Command-X yazın, ardından değişikliklerinizi kaydetmek için “Y” yazın

        Güncellemek için “systemctl” yi yeniden başlatmalıyız:

        sudo systemctl daemon yeniden yükleme

        Hizmeti başlatın:

        sudo systemctl başlangıç ​​teku

        İyi başladığından emin olmak için kontrol edin:

        sudo systemctl durumu teku

        Herhangi bir hata görürseniz, şunu çalıştırarak daha fazla ayrıntı alın:

        sudo journalctl -f -u teku.service

        Teku hizmetini çalıştırarak durdurabilirsiniz:

        sudo systemctl durdurma teku

        Yaygın hatalar için Teku sorun giderme sayfasına bakın veya Teku anlaşmazlığına göz atın, ekip tarafından izlenen.

        İşleri hallettiğinizi hissettiğinizde, aşağıdakileri çalıştırarak kapanırsa hizmeti yeniden başlatmak için etkinleştirin:

        sudo systemctl teku etkinleştir

        İşte aldın! Şu anda işler pişiyor olmalı. Teku hizmetini incelerken, bir Eşitleme Olayını belirten bir dizi günlük göreceksiniz; bu, işaretçi zincirini eşitleyen doğrulayıcınızdır. Başa ulaştığında, bu günlükler Slot Etkinliği olarak değişecek ve ayrıca onay performansınızı ve engelleme tekliflerinizi göreceksiniz..

        Başlatmak

        Kaynak: Beaconcha.in

        1 Aralık, 12:00 UTC’de, Beacon Chain’in ilk blokları doğrulandı. İlk blok geldi Doğrulayıcı 19026, esrarengiz grafiti ile “Bay F buradaydı.” On iki saniye sonra bir sonraki blok geldi; Zug, İsviçre. Eth2 İşaret Zinciri, her 12 saniyede bir blok blok büyüdü. Sonra bir sonraki engel geldi: İlk Dönemi sonuçlandırmak için yeterli doğrulayıcı çevrimiçi olabilir mi? Evet! Doğrulayıcıların% 82,27’si Beacon Chain’in meşhur zemin katı olan Epoch 0’ın geçerliliğini onayladı. İşaretçi Zinciri lansmanı hakkında daha fazla bilgiyi ve sırada ne olduğunu buradan okuyabilirsiniz.. 

        Kaynak: Beaconcha.in

        Şimdi Epoch 760’tayız, bu da Beacon Chain’in neredeyse bir haftadır sorunsuz çalıştığı anlamına geliyor. 

        İşte benim açımdan, bu yazıda açıklanan kurulumu kullanarak, benim açımdan bir çekim:

        Bir sonraki bölümde işlerin nasıl gittiğini özetleyeceğiz. Teku’daki metriklere erişeceğim, AWS çalıştırmanın maliyetini tartışacağım ve ağın durumunu kısaca tartışacağım.

        Bizi izlemeye devam edin!

        Kaynaklar ve bağlantılar

        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 ve Alex Tudorache’ye destek ve teknik yardım için teşekkürler.

        Ethereum 2.0 Haber Bülteni En son Ethereum haberleri, kurumsal çözümler, geliştirici kaynakları ve daha fazlası için haber bültenimize abone olun.

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