Perjalanan Saya Menjadi Validator di Ethereum 2.0, Bagian 2

blog 1NewsPengembangEnterpriseBlockchain DijelaskanAcara dan KonferensiTekanBuletin

Berlangganan newsletter kami.

Alamat email

Kami menghormati privasi Anda

BerandaBlogPengembang

Perjalanan Saya Menjadi Validator di Ethereum 2.0, Bagian 2

Apa saja hal yang harus Anda pertimbangkan ketika memilih perangkat keras dan perangkat lunak untuk menjalankan klien validator Ethereum 2.0? Oleh Coogan BrennanDecember 5, 2020Diposting pada 5 Desember 2020

Perjalanan Saya Menjadi Validator di Ethereum 2 0 Bagian 2

Catatan: Anda masih bisa menjadi validator di jaringan Ethereum 2.0! Akan ada waktu tunggu untuk diaktifkan sebagai validator – mulai 4 Desember 2020, waktu tunggu kira-kira 9,9 hari. Lihat langkah-langkah untuk mempertaruhkan di Bagian 1 seri ini.

  1. Penolakan
  2. pengantar
  3. Pertimbangan Konfigurasi Validator
  1. Perangkat Keras Pemeriksaan Masa Depan
  2. Untuk Menjalankan atau Tidak Menjalankan Klien Eth1?
  3. Hosting Virtual vs. Lokal
  4. Pilihan Klien Eth2 dan Menghindari Hukuman
  • Menyiapkan instans AWS
    1. Sistem operasi
    2. Penetapan harga
    3. Penyimpanan
    4. Pelabuhan
    5. Kunci SSH dan Peluncuran Instance
    6. Menginstal Teku
      1. Persyaratan
      2. Pasang biner
      3. Buat pengguna non-root
      4. Buat layanan systemd
      5. Meluncurkan
      6. Penolakan

        Ini adalah pos yang saya tulis sebagai karyawan ConsenSys dan seseorang yang berencana untuk mempertaruhkan rantai suar. Pernyataan sebelumnya berarti saya memprioritaskan produk ConsenSys (produk ConsenSys biasanya yang terbaik di kelasnya untuk Ethereum, dan saya juga memiliki akses ke tim teknik yang dapat membantu saya menjawab pertanyaan dan memecahkan masalah). Pernyataan terakhir berarti saya mengoptimalkan biaya dan kemudahan penggunaan: Saya tidak memiliki ribuan ETH untuk menghasilkan penghargaan yang substansial, jadi saya mengambil beberapa jalan pintas. Ini adalah keputusan yang saya buat untuk membuat pertaruhan di Ethereum 2.0 sesederhana dan sedapat mungkin dapat diakses oleh individu, tetapi disertai dengan kompromi untuk desentralisasi dan privasi. Namun, Anda dapat mengikuti garis besar tutorial di bawah ini dan membuat pilihan yang berbeda. Faktanya, jika Anda bisa melakukan itu, saya akan mendorong Anda untuk melakukannya! 

        Terakhir, mempertaruhkan Ethereum 2.0 sangat eksperimental dan melibatkan komitmen jangka panjang (saya membagikan tiga tahun). Harap tidak berpartisipasi jika Anda merasa tidak nyaman dengan petugas risiko tingkat tinggi dengan sesuatu yang masih dalam pengembangan. Jika Anda tidak yakin apakah Anda harus mempertaruhkan, silakan bergabung dengan Perselisihan ConsenSys dan tanyakan di saluran # teku-publik. 

        pengantar

        Di posting sebelumnya, kita membahas alasan penyebaran Ethereum 2.0 dan berjalan melalui staking 32 ETH di Kontrak Deposit mainnet Ethereum 1.0. Kami membahas tentang pembuatan kunci dan bagaimana proses taruhannya Landasan peluncuran menautkan Ethereum 1.0 ke 2.0.

        Pada tanggal 23 November, jumlah minimum ETH yang dipertaruhkan untuk meluncurkan Ethereum 2.0 — sekitar 524.288 — terpenuhi. Orang-orang dapat terus mempertaruhkan kontrak dan jumlah validator telah meningkat menjadi lebih dari 33.000 pada 4 Desember.

        Aaron Davis dari MetaMask membagikan pemikirannya di saluran taruhan ConsenSys Slack internal 

        Meskipun sangat mengasyikkan untuk masuk ke blok Genesis sebagai validator, beberapa detik kemudian saya memiliki pengalaman serupa dengan kolega saya Aaron Davis di saluran taruhan ConsenSys internal kami: Untuk tugas gila apa saya mendaftar? Untungnya, saya memiliki akses ke orang-orang yang sangat brilian dan teknis yang cukup dermawan untuk memberikan beberapa tip, petunjuk, dan wawasan tentang menjalankan infrastruktur staking. Saya berharap untuk menyampaikan sebagian kecil dari nasihat berharga itu di sini kepada pihak lain yang berkepentingan.

        Itulah bagian pertama dari artikel ini: Apa saja hal yang harus Anda pertimbangkan ketika memilih perangkat keras dan perangkat lunak untuk menjalankan klien validator Ethereum 2.0? Bagian kedua akan menjelaskan kombinasi perangkat keras / perangkat lunak tertentu yang telah saya pilih untuk klien validator saya. Pilihan yang Anda buat untuk konfigurasi Anda akan bergantung pada sumber daya, kecenderungan pribadi, dan kapasitas teknis Anda. Saya akan melakukan yang terbaik untuk menyoroti bagaimana bias dan keadaan pribadi memengaruhi pilihan saya.

        Terakhir, sebelum kita terjun ke dalamnya, saya ingin mengulangi posting ini hampir seperti entri jurnal untuk pengalaman saya mempertaruhkan 32 ETH (meskipun entri jurnal dengan tambahan teknis yang luas). Karena itu, saya dapat mengubah pendekatan saya sedikit saat rantai suar berkembang. Misalnya, saya berpikir saya pasti akan menggunakan AWS. Seperti yang akan Anda baca di bawah, sekarang saya sedang mempertimbangkannya kembali. Saya juga akan menjelaskan dengan sangat jelas tentang elemen finansial dari taruhan. Staking adalah cara untuk mendukung ekosistem Ethereum, tetapi untuk penggunaan publik yang berkelanjutan, itu juga harus dapat diakses dan memungkinkan bagi orang-orang yang memiliki ETH untuk melakukannya.. 

        Perangkat Keras Pemeriksaan Masa Depan

        Persyaratan dasar untuk menjalankan validator saat ini relatif mudah dipenuhi. Mara Schmiedt dan Collin Meyers ‘ Panduan Validator di Bankless memiliki daftar persyaratan minimum yang baik. Aspek paling menantang dalam menentukan peralatan validator Ethereum 2.0 adalah menyeimbangkan kebutuhan Beacon Chain Phase 0 saat ini dengan permintaan yang tidak diketahui di masa depan saat pengembangan terus berlanjut. (Ini bukan masalah jika Anda merasa nyaman mengawasi validator Anda dengan cermat dan dapat menangani perubahan dengan cepat dan mudah) 

        Ben Edgington, Manajer Proyek Teku dan penerbit Eth2.news, memberi saya beberapa kasus tepi di mana jaringan mungkin menuntut lebih banyak klien validator. Dalam jangka pendek, perhatian terbesar akan menjadi sesuatu seperti ini insiden server waktu Medalla, di mana bug dan perbaikan selanjutnya pada klien Prysm menghentikan finalisasi pada testnet (secara kasar, jaringan tidak dapat “menghasilkan blok”). Karena tidak ada finalitas di jaringan (tidak ada “blok terkonfirmasi”), validator harus menyimpan lebih banyak transaksi di RAM mereka daripada biasanya. 

        Mesin dengan RAM 8GB — yang akan lebih dari cukup dalam keadaan normal — mulai mengalami masalah “kehabisan memori” yang mungkin menyebabkan pemotongan. Lonjakan seperti ini, meskipun tidak biasa, tidak keluar dari pertanyaan untuk mainnet Phase 0.

        Ambiguitas konfigurasi masa depan untuk jaringan adalah penggabungan Ethereum 1.0 dan 2.0 dan pengenalan sharding. Kami masih belum tahu kapan penggabungan tersebut akan terjadi atau apa yang akan mereka butuhkan. Saya ingin memiliki tulang punggung CPU yang kuat saat memasuki Fase 0 (4 inti virtual, RAM 16 GB dengan SSD 100 GB) dan kemudian memfokuskan perhatian saya untuk penyesuaian di masa mendatang seputar ruang penyimpanan (tinggalkan ruang gerak di sini). Harap dicatat ini mungkin berubah menjadi berlebihan dan memakan hadiah staking.

        Itu adalah “yang tidak diketahui yang diketahui” di masa depan, mari kita bahas poin keputusan konfigurasi utama untuk validator hari ini.

        Untuk Menjalankan atau Tidak Menjalankan klien Eth1?

        Ini adalah ritual yang saya coba untuk membuat siswa bootcamp kami sesering mungkin: menyinkronkan klien Ethereum 1.0. Ini adalah rahasia umum bahwa sebenarnya menghosting node Ethereum 1.0 “penuh” adalah tindakan cinta, bukan solusi Dilema Tahanan yang mengeras. “Penuh” harus diberi tanda petik karena bahkan pengembang inti Ethereum mengalami kesulitan untuk menyetujui definisi tentang apa sebenarnya arti “node penuh”.

        Satu hal yang dapat kita sepakati bersama: Dibutuhkan lebih banyak waktu dan penyimpanan untuk menyinkronkan klien Ethereum 1.0 daripada yang Anda bayangkan. Validator kami harus memiliki cara untuk menanyakan basis data jaringan Ethereum 1.0 (kita akan membahas alasannya nanti). Jika Anda ingin menghemat ruang dan pusing saat menyinkronkan secara lokal, Anda dapat menggunakan titik akhir Infura, yang tersedia secara gratis dengan registrasi. 

        Meskipun ini menghemat penyimpanan yang signifikan dan perhatian logistik, ini mengorbankan sejumlah desentralisasi untuk jaringan Eth1 dan Eth2 secara bersamaan. Jika Infura jatuh, yang sangat jarang tetapi memang terjadi, yang akan menyebabkan efek riak di seluruh validator Ethereum 2.0 yang menggunakannya untuk titik akhir Ethereum 1.0 mereka. Sesuatu untuk dipertimbangkan!

        (Hanya untuk memperjelas: kesulitan menyinkronkan simpul penuh Ethereum berkaitan dengan sifat keadaan dunia Ethereum, bukan dengan pengembang inti Ethereum 1.0 yang telah melakukan pekerjaan luar biasa dalam menangani masalah yang sangat menantang ini.)

        Hosting Virtual vs Lokal

        Pertimbangan berikutnya bagi saya adalah menghosting node validator secara lokal (di rumah saya) atau secara virtual (di penyedia layanan virtual seperti Amazon Web Services (AWS), Digital Ocean, dll.). Seperti yang saya sebutkan di bagian sebelumnya, saya tidak percaya diri untuk menjalankan node validator yang konsisten dari rumah, bahkan di laptop lama yang disimpan di suatu tempat. Kikuk dan konyol, saya akan menendang atau melupakannya.

        Saya memilih untuk menjalankan node saya di AWS karena itulah yang paling saya kenal (Namun, setelah melalui seluruh proses ini, saya menebak-nebak keputusan ini. Saya akan membahasnya nanti). Pengorbanan di sini sekali lagi adalah desentralisasi: Jika AWS turun atau mengalami masalah (seperti yang terjadi baru-baru ini), Saya atas belas kasihan mereka. Jika cukup banyak orang yang menjalankan node di AWS, itu dapat memengaruhi jaringan Ethereum yang lebih besar.

        Orang mungkin akan memilih sendiri untuk yang satu ini. Hosting lokal adalah jenis proyek khusus dan tidak semua orang memiliki waktu, sumber daya, atau komitmen yang diperlukan. Meskipun hosting virtual adalah kekuatan sentralisasi, saya memilih untuk menggunakannya karena kemudahan penggunaan dan (mudah-mudahan) jaminan uptime. 

        Jika Anda ingin menjalankan node validator secara lokal, Anda masih dapat mengikuti arahan umum dari tutorial ini, Seri tutorial Somer Esat yang luar biasa dengan klien yang berbeda atau bahkan menyinkronkan Raspberry Pi Model 4B dengan RAM 8GB dengan Ethereum di ARM. (Sinkronisasi di Raspberry Pi masih sangat eksperimental dan orang-orang harus menunggu sampai Ethereum di tim ARM mengonfirmasi stabilitasnya)

        Pilihan Klien Eth2 dan Menghindari Hukuman

        Pilihan utama lainnya adalah klien Ethereum 2.0 di antara klien yang sudah ada: Mercu suar, Pedoman, Nimbus, Prysm dan Teku. Saya sangat bias terhadap Teku dan tidak cukup paham untuk memperdebatkan poin-poin penting dari klien. Artikel ini adalah gambaran yang layak tentang kinerja klien di Medalla. (Ingatlah bahwa Medalla menuntut lebih banyak dari prosesor daripada mainnet.)

        Proof of Stake menggabungkan disinsentif eksplisit untuk mendorong perilaku yang benar di jaringan. Ini mengambil bentuk validator dinging untuk offline dan langkah yang lebih dramatis dari pemotongan aktor untuk mengambil tindakan jahat terhadap jaringan, secara sadar atau tidak..

        Masalah paling umum adalah memastikan validator Anda tersedia untuk jaringan. Ini berarti memastikan validator Anda online. Ada pendekatan DevOps untuk masalah ini — membuat sistem pemantauan dan peringatan untuk memberi tahu Anda jika validator Anda offline — yang tidak akan saya bahas di sini.

        Tetapi ada cara lain agar tidak tersedia ke jaringan, dan itu adalah jika klien Anda mulai berperilaku buruk karena satu dan lain alasan. Setelah bug server waktu menyebabkan perlambatan jaringan di Medalla, pengembang inti Eth2 berkumpul untuk berkembang “[A] format standar untuk mentransfer riwayat penandatanganan kunci memungkinkan validator untuk dengan mudah beralih antar klien tanpa risiko menandatangani pesan yang bentrok.” Tidak semua klien memiliki perlindungan ini, tetapi Teku memilikinya. Di sinilah Anda dapat membaca tentang menggunakan Teku’s Slash Protection (berjalan secara default) termasuk bermigrasi antara node Teku atau node non-Teku ke Teku.

        Jika Anda mengalami masalah dengan klien Anda dan perlu me-restart seluruh jaringan, Anda harus waspada terhadap Subjektivitas Lemah. Proof of Work memungkinkan siapa saja untuk kembali ke blok genesis jaringan dan tanpa kepercayaan membangun status jaringan dari awal. Proof of Stake, bagaimanapun, memiliki batasan dalam hal itu: Jika sepertiga dari validator jaringan pada titik tertentu keluar namun terus menandatangani blok dan pengesahan, mereka dapat mengubah status jaringan dan memasukkan data palsu itu ke node yang disinkronkan ke jaringan jika pelaku jahat menangkap node sinkronisasi sebelum node sinkronisasi mencapai tempat validator menarik dana mereka. Anda dapat membaca lebih lanjut di sini, tetapi jawaban singkatnya adalah Anda harus memiliki “pos pemeriksaan subjektivitas yang lemah” atau file status yang dikodekan, yang pada dasarnya merupakan arsip jaringan. Teku menyediakan flag start-up untuk keduanya.

        Masalah penalti terakhir adalah yang paling serius: Pemotongan. Pemotongan terjadi ketika staker bekerja melawan aturan jaringan. Ini berbeda dengan mendapatkan penalti karena offline. Ini secara aktif bekerja melawan jaringan dengan mengirimkan informasi validator yang bertentangan. Ada beberapa materi yang sangat bagus untuk mempelajari lebih lanjut tentang pemotongan dan cara mencegahnya:

        Kesimpulan utamanya adalah jangan menjalankan satu kunci validator pada beberapa klien. Rupanya inilah yang menyebabkan peristiwa pemotongan pertama, yang terjadi pada 2 Desember. Ada sejumlah pemotongan sejak itu! Jika Anda bermigrasi dari satu contoh ke contoh lainnya, periksa empat kali lipat Anda tidak akan memiliki dua mesin yang bekerja dari kunci yang sama:

        Papa Ben mengatakannya seperti itu. Sumber

        Spesifikasi Konfigurasi AWS + Infura + Teku Validator

        Pengaturan blok Genesis saya:

        Sistem operasi: Ubuntu Server 20.04 LTS (HVM) (Amazon Web Service)

        Prosesor: Prosesor Intel Xeon Platinum 8000 series, 3.1 GHz. (Layanan Web Amazon)

        Penyimpanan: 4 inti virtual, RAM 16 GB (Amazon Web Service)

        Penyimpanan: 100GB SSD, 300/3000 IOPS (Amazon Web Service)

        Klien Ethereum 1.0: Infura endpoint (tingkat gratis)

        Klien Ethereum 2.0: Teku

        Melihat semua pertimbangan di atas, saya tidak yakin dengan pendekatan terbaik untuk membangun pengaturan validator. Untuk diri saya sendiri, saya ingin memilih mesin dan secara umum tidak khawatir untuk mengubahnya setidaknya selama dua tahun. Ini membantu biaya validator keseluruhan (saya bisa mendapatkan diskon yang signifikan dari mengunci dengan penyedia virtual selama beberapa tahun) dan saya tidak terlalu gesit dengan menjalankan server. Pendekatan pembuktian masa depan atau “spesifikasi berlebih” ini semoga membuat hidup saya selama dua tahun ke depan sedikit lebih mudah.

        Awalnya, saya yakin AWS adalah platform virtual terbaik dan itu adalah layanan yang akan saya gunakan untuk postingan ini dan berikutnya. Namun, setelah melalui seluruh proses, saya menyadari AWS mungkin berlebihan untuk pengembang individu. Kekuatan nyata AWS tampaknya adalah kapasitasnya untuk secara dinamis meningkatkan untuk memenuhi permintaan yang datang dengan biaya premium. Ini masuk akal secara ekonomi untuk skala besar, proyek tingkat perusahaan, tetapi Ethereum 2.0 individu arus persyaratan klien tidak membutuhkan ketelitian seperti itu.

        Saya akan melanjutkan dengan AWS tetapi juga menghibur opsi menjalankan instans di Digital Ocean, yang mungkin lebih sesuai untuk pengembang individu. Lebih lanjut tentang itu di kemudian hari.

        Siapkan Akun Infura

        Saya memilih untuk menggunakan Infura sebagai titik akhir Ethereum 1.0 saya. Untuk saat ini, rantai suar sedang mengawasi Kontrak Setoran di Ethereum 1.0 untuk mengaktifkan pemegang saham baru ketika mereka telah menyetorkan 32 ETH dengan benar dan menyerahkan tanda tangan BLS yang sesuai.

        Di masa mendatang, rantai suar akan mulai menguji pemrosesan lebih lanjut dengan mulai menggunakan informasi status dari Ethereum 1.0 untuk membuat pos pemeriksaan paralel pada rantai suar.

        Seperti yang kami sebutkan di atas, ada dua cara utama untuk memiliki visibilitas ke jaringan Ethereum 1.0. Salah satunya adalah menyinkronkan dan secara aktif memelihara node Ethereum 1.0, yang membuat database status Ethereum 1.0 lokal. Yang lainnya adalah menggunakan layanan seperti Infura, yang menyediakan titik akhir Ethereum 1.0 yang mudah, dapat diakses melalui HTTPS atau WebSockets.

        Daftar akun di sini. Setelah Anda memiliki akun, klik logo Ethereum di sisi kiri.

        Klik “Buat Proyek Baru” di pojok kanan atas

        Beri nama proyek Anda (milik saya adalah “Eth 2 Validator”), dan buka “Pengaturan”, pastikan titik akhir jaringan Anda adalah “Mainnet” dan salin titik akhir HTTPS:

        Kami akan menggunakan ini nanti untuk perintah start-up klien Teku kami!

        Menyiapkan instans AWS

        Menyiapkan instans EC2 di Amazon sangatlah mudah. Kami akan memiliki beberapa penyesuaian di sana-sini untuk membantu instance virtual kami berfungsi dengan baik dengan Teku.

        Buat akun AWS (berbeda dari akun Amazon.com) dan masuk ke Konsol AWS. Buka halaman EC2, yang akan terlihat seperti ini:

        Klik tombol “Luncurkan Instance”. Anda kemudian akan melihat layar berikut:

        Sistem operasi

        Di sinilah kami memilih gambar mesin apa (yang saya anggap sebagai sistem operasi) yang ingin kami gunakan pada instance virtual kami. Saya memilih Ubuntu Server 20.04, yang merupakan lingkungan Server berbasis Linux. Lingkungan Server Ubuntu memiliki beberapa perbedaan pengoptimalan utama dari lingkungan Desktop Ubuntu. Perbedaan utama untuk tujuan kami adalah Server Ubuntu tidak memiliki Antarmuka Pengguna Grafis (GUI). Ke mana kita pergi, hanya ada baris perintah! Membawa saya kembali ke hari-hari Apple II saya.

        Setelah memilih sistem operasi kami, kami kemudian memilih jenis instans kami:

        Menurut saya menu ini cukup banyak, jadi saya akan menjelaskannya sedikit untuk Anda. Di sini kami memilih inti komputasi / daya RAM / CPU untuk mesin kami. Ini adalah “mentah” atau “memori aktif” mesin dan terpisah dari penyimpanan (hard drive) perangkat. Anggap saja sebagai mesin instance virtual kami, tempat kami akan menjalankan sistem operasi Server Ubuntu kami. AWS memisahkan ini menjadi keluarga instans terpisah yang dilambangkan dengan kombinasi huruf / angka di kolom paling kiri.

        Keluarga instans memiliki pengaturan perangkat keras yang berbeda seperti halnya mesin mobil yang berbeda memiliki konfigurasi piston, busi, dan bahan bakar yang berbeda untuk memenuhi permintaan yang berbeda. Kami akan fokus pada dua keluarga contoh “komputasi umum” mereka, m5 dan t3.

        Saya memilih instance m5.xlarge, yang menyediakan 4 inti komputasi virtual (vCPU) dan RAM 16 GB. Setelah menjalankan mainnet Ethereum 2.0 selama sekitar satu hari, mesin saya belum menggunakan lebih dari 4% dari vCPU yang tersedia. Seperti yang disebutkan di bagian “Pemeriksaan Masa Depan” di atas, permintaan jaringan Ethereum 2.0 hanya akan tumbuh. Tetapi untuk beberapa bulan ke depan, tidak ada lonjakan jaringan besar yang berkepanjangan, saya kemungkinan besar akan baik-baik saja dengan instans m5.large (2 inti virtual / vCPU, RAM 8GB)

        Orang-orang teknis yang lebih paham dari saya juga merekomendasikan contoh t3.large sebagai opsi yang masuk akal untuk Ethereum 2.0. t3.large memiliki 2 vCPU dan memori 8 GB, sama dengan m5.large, tetapi kelompok t3 dibuat untuk aktivitas jaringan yang lebih “dapat meledak” (lonjakan dalam CPU) daripada kelompok m5 yang dibuat untuk beban CPU yang konsisten.

        Penetapan harga

        Hal terakhir yang perlu disebutkan sebelum kita beralih ke penyimpanan adalah harga. AWS mahal dibandingkan dengan opsi lain seperti Digital Ocean. Anda membayar CPU (keluarga instance Anda) dan penyimpanan (hard-drive Anda) secara terpisah berdasarkan apa yang Anda gunakan. CPU dibayar per jam. Karena validator harus online 24 jam, Anda dapat menggunakan tabel harga di bawah ini (mulai Desember 2020) untuk membuat beberapa perhitungan kasar: 

        Ini adalah harga sesuai permintaan. AWS memang menyediakan sesuatu yang disebut Harga Instans Cadangan, di mana jika Anda berjanji untuk memiliki mesin virtual dari satu tahun hingga tiga tahun, Anda bisa mendapatkan pengurangan biaya hingga 50-60% dari tabel harga di atas. (Terima kasih kepada Jason Chroman untuk tip ini!)

        Dari beranda EC2, klik “Instans Cadangan” di menu sebelah kiri, yang ditunjukkan di bawah ini:

        Klik “Beli Instans Cadangan”:

        Di menu yang muncul, masukkan detail jenis instans dan jumlah waktu yang diinginkan untuk melihat harga (Saya memilih m5.xlarge dan jangka waktu 36 bulan):

        Klik “Cari” dan lihat opsi harga:

        Ada diskon harga yang signifikan, saya yakin lebih dari 50%, tapi saya terkunci selama tiga tahun. Setelah Anda membeli Instans Cadangan, AWS kemudian menerapkannya ke kotak virtual yang ada atau akan menerapkannya setelah diluncurkan. Ingat ini TIDAK termasuk ruang penyimpanan (hard-drive). 

        Catatan: Saya belum melakukan ini, karena saya belum yakin AWS adalah opsi terbaik untuk individu yang mempertaruhkan satu hingga tiga node validator Ethereum 2.0. Saya menjalankan sebuah instance dengan harga sesuai permintaan untuk melihat bagaimana kelanjutannya sebelum melakukan. 

        Penyimpanan

        Kembali ke proses peluncuran instance kami, kami beralih ke tab “Tambahkan Penyimpanan”

        Orang-orang teknis brilian yang saya temui merekomendasikan jumlah penyimpanan 100GB SSD Tujuan Umum. Penyimpanan biasanya bukan penghambat dengan klien Eth2. Bagaimanapun, ini adalah tanpa menjalankan klien Eth1 penuh. Untuk penyimpanan Eth1, perkiraan konservatif adalah sekitar 1TB. Pastikan untuk memperhitungkan ini jika Anda tidak menggunakan Infura.

        Saya tidak tahu unit di kolom IOPS pada gambar di atas, tetapi ini adalah input-output untuk hard drive yang berkomunikasi dengan CPU. Ini adalah hambatan klasik untuk sinkronisasi node Eth1 penuh. Jika Anda ingin menyinkronkan klien Eth1 lengkap di komputer ini dan Anda mengalami masalah, ini bisa menjadi tempat untuk mencarinya.

        Pelabuhan

        Melompati “Tambahkan Tag”, lanjutkan ke “Konfigurasi Grup Keamanan”. Ini adalah bukaan berbeda yang dibuat untuk berbagai jenis komunikasi masuk dan keluar dengan instans.

        AWS secara otomatis membuka port SSH tradisional, karena itulah cara utama kami berinteraksi dengan instans. Kacang Mete dan Somer Esat panduan yang sangat baik merekomendasikan untuk menonaktifkan akses kata sandi untuk SSH, tetapi kami akan melihat saat kami meluncurkan instans yang bukan merupakan opsi default untuk AWS. Namun, ada baiknya untuk mengacak port SSH Anda ke nomor antara 1024-65535. Ini untuk mencegah pelaku jahat memindai jaringan port SSH standar. Lihat cara mengamankan port SSH Anda secara umum sini dan khusus untuk AWS sini.

        Kami harus menambahkan dua aturan keamanan untuk mengakomodasi klien Teku dan ini berkaitan dengan komunikasi peer-to-peer. Jaringan blockchain terdesentralisasi dalam arti node berbicara langsung satu sama lain. Daripada berkonsultasi dengan node pusat, node individu akan mengembangkan dan mempertahankan pemahaman tentang keadaan jaringan dengan “bergosip” dengan banyak node. Ini berarti ketika satu klien berjabat tangan dengan yang lain, mereka bertukar informasi tentang jaringan. Dilakukan cukup waktu dengan node yang berbeda, informasi menyebar ke seluruh jaringan. Saat ini, node Validator Eth2 saya memiliki 74 rekan yang mengobrol.

        Teku berkomunikasi dengan node lain di port 9000, jadi kami akan membukanya untuk UDP dan TCP, dua jenis protokol komunikasi. 

        Setelah itu, akan terlihat seperti ini:

        Kunci SSH dan Peluncuran Instance

        Terakhir, buka “Tinjau dan Luncurkan”, ikhtisar pilihan yang dibuat. Setelah disetujui, akan ada menu pop-up tentang kunci SSH. Saya tidak menampilkan milik saya karena berisi informasi sensitif. Yakni, keypair yang digunakan untuk mengotentikasi dan masuk ke instance virtual melalui SSH (baris perintah lokal). Jika Anda belum memiliki pasangan, AWS akan membuatkannya untuk Anda. Anda harus mengunduh ini dan memperlakukannya seperti kunci pribadi Ethereum! Ini adalah satu-satunya cara untuk terhubung ke instans Anda dan AWS tidak akan menyimpannya untuk Anda.

        Setelah semuanya keren, jendela ini akan muncul:

        Baik! Selesai, mari beralih ke mengakses dan mengamankan instance kita, lalu menginstal dan menjalankan Teku!

        Mengakses Instance

        Cara utama untuk mengakses instans AWS adalah melalui SSH, “Protokol kriptografi untuk mengoperasikan layanan jaringan dengan aman melalui jaringan yang tidak aman.” Seperti yang disebutkan sebelumnya, AWS secara default menonaktifkan otentikasi kata sandi untuk mengakses instans. Anda hanya dapat menggunakan pasangan kunci yang dibuat sebelum peluncuran instans. Keypair harus memiliki akhiran file a.pem. 

        AWS menyediakan cara yang bersih untuk mendapatkan perintah SSH Anda. Mengklik instans yang sedang berjalan dari halaman EC2 utama Anda, ada tombol di kanan atas yang bertuliskan “hubungkan”:

        Di halaman berikutnya akan ada perintah SSH khusus untuk instance Anda. Ini akan terstruktur seperti ini:

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [email dilindungi]_IDENTIFIER.compute-ZONE.amazonaws.com

        Memasukkan perintah ini ke terminal akan memulai sesi SSH. Pertama kali, mesin lokal akan menanyakan apakah Anda ingin mempercayai sidik jari ECDSA yang disediakan oleh AWS. Ini untuk mencegah a serangan man-in-the-middle dan, jika khawatir, pengguna bisa mengikuti sidik jari instance mereka langkah-langkah ini.

        Di terminal yang terpisah dari sesi SSH saat ini, transfer file kunci validator yang diperlukan untuk menjalankan Teku. Di posting blog sebelumnya, kami berjalan melalui staking 32 ETH dan mendapatkan kunci validator untuk Ethereum 2.0. Pada akhirnya, kami memiliki struktur file ini:

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

        Kita perlu mentransfer file validator_key_info ke virtual instance kita. Secure Copy Protocol (scp) memungkinkan kita melakukan ini dengan aman. Sesuaikan perintah scp generik di bawah ini menggunakan jalur ke direktori di atas dan perintah SSH sebelumnya:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [email dilindungi]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (Perhatikan “: ~” di akhir seluruh perintah.)

        Anda akan melihat transfer file terjadi. Jika Anda menavigasi kembali ke sesi SSH dan mengetik ls, Anda akan melihat direktori yang ditransfer.

        Menginstal Teku

        Sekarang kami memiliki file validator yang kami butuhkan, kami akan menginstal Teku. Pertama, kita harus memperbarui program yang ada dan menginstal sistem Java yang diperlukan:

        Instal Java

        pembaruan sudo apt && sudo apt menginstal default-jre && sudo apt install default-jdk

        Periksa ulang Java yang diinstal berhasil dengan:

        java -version

        Instal Binary

        Temukan rilis Teku stabil terbaru di sini. Salin alamat tautan ke file tar.gz, lalu dari sesi SSH Anda, unduh. Ini tampilan saya, versi Anda kemungkinan besar akan berbeda:

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

        Dekompresi file yang diunduh dengan perintah berikut. Jika Anda memiliki versi yang berbeda, gunakan sub nama file tersebut sebagai lawan dari teku-20.11.1.tar.gz:

        tar -zxvf teku-20.11.1.tar.gz

        Demi kebersihan, hapus file tar.gz.

        Setelah semua langkah ini, berikut tampilan direktori home Anda (nomor versi dan konten Teku mungkin berbeda:

        ubuntu / └── teku-20.11.1 / ├── LISENSI ├── bin / ├── lib / ├── license-dependency.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

        Buat pengguna non-root

        Langkah ini disalin dari Somer Esat tutorial Ubuntu / Teku yang sangat baik

        Kami akan membuat pengguna non-root bernama teku yang dapat mengoperasikan Teku. Ketik yang berikut di bawah ini:

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

        Kami juga akan membuat direktori data khusus untuk Teku, lalu memberi pengguna teku akses ke sana:

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

        Buat layanan systemd

        Langkah ini diadaptasi dari Somer Esat’s tutorial Ubuntu / Teku yang sangat baik

        Langkah ini akan membuat layanan yang akan menjalankan Teku di latar belakang. Ini juga akan memungkinkan mesin untuk secara otomatis memulai ulang layanan jika berhenti karena alasan tertentu. Ini adalah langkah penting untuk memastikan validator kami berjalan 24-7.

        Buat file layanan dengan menggunakan editor teks nano:

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

        Dalam file ini (yang seharusnya kosong), kami akan memasukkan serangkaian perintah untuk dieksekusi oleh systemd saat kami memulai layanan. Berikut kode di bawah ini, Anda harus memasukkan item berikut yang telah kami kumpulkan sepanjang perjalanan ini:

        • Titik Akhir HTTP Infura Eth1
        • validator_key_info path direktori dengan dua file terkait kunci yang valid
        • Jalur data khusus (lib / var / teku)

        Masukkan nilai-nilai tersebut dalam kode tebal di bawah ini, lalu salin semuanya ke editor teks nano:

        [Unit] Description = 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 –validator-keys = / home / ubuntu / validator_key_info / KEYSTORE-M_123456_789_ABCD.json: /home/ubuntu/validator_key_info/validator_keys/KEYSTORE-M_123456 –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –jalur basis data = / var / lib / teku [Instal] WantedBy = multi-user.target

        Ketik command-X, lalu ketik “Y” untuk menyimpan perubahan Anda

        Kami harus memulai ulang “systemctl” untuk memperbaruinya:

        sudo systemctl daemon-reload

        Mulai layanan:

        sudo systemctl mulai teku

        Periksa untuk memastikan semuanya mulai baik-baik saja:

        sudo systemctl status teku

        Jika Anda melihat kesalahan apa pun, dapatkan detail selengkapnya dengan menjalankan:

        sudo journalctl -f -u teku.service

        Anda dapat menghentikan layanan Teku dengan menjalankan:

        sudo systemctl berhenti teku

        Periksa halaman pemecahan masalah Teku untuk kesalahan umum atau periksa perselisihan Teku, yang diawasi oleh tim.

        Setelah Anda merasa telah menyelesaikan masalah, aktifkan layanan untuk memulai ulang jika dimatikan dengan menjalankan:

        sudo systemctl mengaktifkan teku

        Itu dia! Semuanya harus masak sekarang. Saat memeriksa layanan Teku, Anda akan melihat serangkaian log yang mencatat Peristiwa Sinkronisasi, ini adalah validator Anda yang menyinkronkan rantai suar. Setelah mencapai head, log tersebut akan berubah menjadi Peristiwa Slot, dan Anda juga akan melihat kinerja pengesahan dan memblokir proposal.

        Meluncurkan

        Sumber: Beaconcha.in

        Pada tanggal 1 Desember pukul 12 siang UTC, blok pertama Beacon Chain divalidasi. Blok pertama berasal Validator 19026, dengan coretan misterius, “Tuan F ada di sini.” Dua belas detik kemudian datang blok berikutnya, coretan yang menunjukkan validator mungkin berada Zug, Swiss. Rantai Beacon Eth2 tumbuh dengan mantap, blok demi blok setiap 12 detik. Lalu datang rintangan berikutnya: apakah cukup validator yang online untuk menyelesaikan Epoch pertama? Iya! 82,27% validator membuktikan validitas Epoch 0, pepatah dasar Beacon Chain. Anda dapat membaca lebih lanjut tentang peluncuran Beacon Chain, dan apa yang selanjutnya, di sini. 

        Sumber: Beaconcha.in

        Kami sekarang berada di Epoch 760, yang berarti Rantai Beacon telah berjalan dengan lancar selama hampir seminggu. 

        Berikut adalah jepretan dari perspektif saya tentang momen genesis, menggunakan penyiapan yang dijelaskan dalam postingan ini:

        Dalam angsuran berikutnya, kami akan melakukan rekap tentang bagaimana keadaannya. Saya akan mengakses metrik dari Teku, membahas biaya menjalankan AWS, dan membahas secara singkat status jaringan.

        Tetap disini!

        Sumber daya dan tautan

        Terima kasih kepada 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, dan Alex Tudorache untuk dukungan dan bantuan teknis.

        Ethereum 2.0Newsletter Berlangganan buletin kami untuk berita Ethereum terbaru, solusi perusahaan, sumber daya pengembang, dan banyak lagi.

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