การเดินทางของฉันสู่การเป็น Validator บน Ethereum 2.0 ตอนที่ 2

บล็อก 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressจดหมายข่าว

สมัครรับจดหมายข่าวของเรา.

ที่อยู่อีเมล

เราเคารพความเป็นส่วนตัวของคุณ

หน้าแรก

การเดินทางของฉันสู่การเป็น Validator บน Ethereum 2.0 ตอนที่ 2

มีสิ่งใดบ้างที่คุณควรพิจารณาเมื่อเลือกฮาร์ดแวร์และซอฟต์แวร์เพื่อเรียกใช้ไคลเอ็นต์ตัวตรวจสอบความถูกต้อง Ethereum 2.0 โดย Coogan Brennan ธันวาคม 5, 2020 โพสต์เมื่อธันวาคม 5, 2020

การเดินทางของฉันสู่การเป็นผู้ตรวจสอบความถูกต้องบน Ethereum 2 0 ตอนที่ 2


หมายเหตุ: คุณยังสามารถเป็นตัวตรวจสอบความถูกต้องบนเครือข่าย Ethereum 2.0 ได้! จะมีเวลารอเพื่อเปิดใช้งานเป็นตัวตรวจสอบความถูกต้อง – ณ วันที่ 4 ธันวาคม 2020 เวลารอประมาณ 9.9 วัน. ดูขั้นตอนในการปักหลักในส่วนที่ 1 ของซีรีส์นี้.

  1. ข้อจำกัดความรับผิดชอบ
  2. บทนำ
  3. การพิจารณาการกำหนดค่า Validator
  1. ฮาร์ดแวร์พิสูจน์อักษรในอนาคต
  2. เพื่อเรียกใช้หรือไม่เรียกใช้ไคลเอ็นต์ Eth1?
  3. Virtual กับ Local Hosting
  4. Eth2 Client Choice และการหลีกเลี่ยงบทลงโทษ
  • การตั้งค่าอินสแตนซ์ AWS
    1. ระบบปฏิบัติการ
    2. ราคา
    3. การจัดเก็บ
    4. พอร์ต
    5. คีย์ SSH และการเปิดตัวอินสแตนซ์
    6. การติดตั้ง Teku
      1. ข้อกำหนด
      2. ติดตั้งไบนารี
      3. สร้างผู้ใช้ที่ไม่ใช่รูท
      4. สร้างบริการ systemd
      5. เปิด
      6. คำเตือน

        นี่คือโพสต์ที่ฉันเขียนในฐานะพนักงานของ 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 – ผู้คนสามารถมีส่วนร่วมในสัญญาต่อไปและจำนวนผู้ตรวจสอบความถูกต้องเพิ่มขึ้นเป็นมากกว่า 33,000 คน ณ วันที่ 4 ธันวาคม.

        Aaron Davis จาก MetaMask แบ่งปันความคิดของเขาในช่องการวางเดิมพัน ConsenSys Slack ภายใน 

        ในขณะที่มันน่าตื่นเต้นมากที่ได้นำมันเข้าสู่ Genesis block ในฐานะผู้ตรวจสอบความถูกต้อง แต่ไม่กี่วินาทีต่อมาฉันก็มีประสบการณ์คล้าย ๆ กันกับ Aaron Davis เพื่อนร่วมงานของฉันในช่องการวางเดิมพัน ConsenSys ภายในของเรา: ฉันสมัครงานบ้าอะไร? โชคดีที่ฉันสามารถเข้าถึงคนที่มีเทคนิคและมีเทคนิคที่ยอดเยี่ยมมากพอที่จะให้คำแนะนำคำแนะนำและข้อมูลเชิงลึกเกี่ยวกับการใช้โครงสร้างพื้นฐาน ฉันหวังว่าจะส่งต่อเศษเสี้ยวของคำแนะนำที่มีค่านี้ให้กับผู้สนใจรายอื่น ๆ.

        ส่วนแรกของบทความนี้จะเป็นอย่างไร: มีสิ่งใดบ้างที่คุณควรพิจารณาเมื่อเลือกฮาร์ดแวร์และซอฟต์แวร์เพื่อเรียกใช้ไคลเอ็นต์ตัวตรวจสอบความถูกต้อง Ethereum 2.0 ส่วนที่สองจะอธิบายถึงชุดฮาร์ดแวร์ / ซอฟต์แวร์เฉพาะที่ฉันได้เลือกไว้สำหรับไคลเอ็นต์ตัวตรวจสอบความถูกต้องของฉัน ตัวเลือกที่คุณเลือกสำหรับการกำหนดค่าของคุณจะขึ้นอยู่กับทรัพยากรความชอบส่วนบุคคลและความสามารถทางเทคนิคของคุณ ฉันจะพยายามอย่างเต็มที่เพื่อเน้นให้เห็นว่าอคติและสถานการณ์ส่วนตัวเป็นตัวบอกทางเลือกของฉันอย่างไร.

        สุดท้ายนี้ก่อนที่เราจะเข้าสู่บทความนี้ฉันอยากจะย้ำอีกครั้งว่าโพสต์เหล่านี้เกือบจะเหมือนกับรายการบันทึกประจำวันสำหรับประสบการณ์ของฉันที่วางเดิมพัน 32 ETH (แม้ว่าจะเป็นรายการบันทึกประจำวันที่มีส่วนช่วยทางเทคนิคมากมาย) ด้วยเหตุนี้ฉันอาจเปลี่ยนแนวทางของฉันเล็กน้อยเมื่อห่วงโซ่สัญญาณดำเนินไป ตัวอย่างเช่นฉันคิดว่าฉันจะใช้ AWS อย่างแน่นอน ดังที่คุณจะอ่านด้านล่างตอนนี้ฉันกำลังพิจารณาเรื่องนี้อีกครั้ง ฉันจะมีความชัดเจนมากเกี่ยวกับองค์ประกอบทางการเงินของการเดิมพัน การปักหลักเป็นวิธีหนึ่งในการสนับสนุนระบบนิเวศของ Ethereum แต่เพื่อการใช้งานสาธารณะที่ยั่งยืนควรเข้าถึงและเป็นไปได้สำหรับผู้ที่มี ETH ในการทำเช่นนั้น. 

        ฮาร์ดแวร์พิสูจน์อักษรในอนาคต

        ข้อกำหนดพื้นฐานสำหรับการเรียกใช้โปรแกรมตรวจสอบความถูกต้องในปัจจุบันเป็นเรื่องง่ายที่จะตอบสนอง Mara Schmiedt และ Collin Meyers คู่มือการตรวจสอบ ใน Bankless มีข้อกำหนดขั้นต่ำที่ดี สิ่งที่ท้าทายที่สุดในการพิจารณาอุปกรณ์ตรวจสอบความถูกต้อง Ethereum 2.0 คือการสร้างสมดุลระหว่างความต้องการปัจจุบันของ Beacon Chain Phase 0 กับความต้องการที่ยังไม่ทราบในอนาคตในขณะที่การพัฒนาดำเนินต่อไป (นี่ไม่น่ากังวลหากคุณสบายใจที่จะดูแลตัวตรวจสอบความถูกต้องของคุณอย่างใกล้ชิดและสามารถจัดการกับการเปลี่ยนแปลงได้อย่างรวดเร็วและง่ายดาย) 

        Ben Edgington ผู้จัดการโครงการ Teku และผู้จัดพิมพ์ของ Eth2.news, แจ้งให้ฉันทราบถึงกรณีขอบบางอย่างที่เครือข่ายอาจต้องการไคลเอนต์ validator เพิ่มเติม ในระยะสั้นสิ่งที่น่ากังวลที่สุดก็คือ เหตุการณ์เซิร์ฟเวอร์เวลา Medalla, ซึ่งข้อบกพร่องและการแก้ไขในภายหลังในไคลเอนต์ Prysm ได้หยุดการสรุปขั้นสุดท้ายบน testnet (พูดอย่างคร่าวๆคือเครือข่ายไม่สามารถ“ สร้างบล็อก” ได้) เนื่องจากไม่มีการสิ้นสุดบนเครือข่าย (ไม่มี “บล็อกที่ยืนยัน”) ผู้ตรวจสอบความถูกต้องจึงต้องมีธุรกรรมใน RAM มากกว่าปกติ. 

        เครื่องที่มี RAM 8GB ซึ่งน่าจะเกินพอภายใต้สถานการณ์ปกติเริ่มพบปัญหา“ หน่วยความจำไม่เพียงพอ” ซึ่งอาจนำไปสู่การเจ็บแสบได้ การพุ่งสูงขึ้นเช่นนี้แม้ว่าจะผิดปกติ แต่ก็ไม่พ้นคำถามสำหรับเมนเน็ตเฟส 0.

        ความคลุมเครือในการกำหนดค่าเครือข่ายในอนาคตคือการรวม Ethereum 1.0 และ 2.0 เข้าด้วยกันและการนำเอาการแบ่งส่วน เรายังไม่รู้ว่าการรวมเหล่านั้นจะเกิดขึ้นเมื่อใดหรือจะต้องเป็นอย่างไร ฉันต้องการให้ CPU เป็นกระดูกสันหลังที่แข็งแกร่งใน Phase 0 (4 virtual core, 16GB RAM พร้อม 100GB SSD) จากนั้นมุ่งความสนใจไปที่การปรับเปลี่ยนพื้นที่จัดเก็บในอนาคต (ออกจากห้อง wiggle ที่นี่) โปรดทราบว่านี่อาจกลายเป็นการกินมากเกินไปและกินผลตอบแทนจากการเดิมพัน.

        สิ่งเหล่านี้คือ “สิ่งที่ไม่รู้จัก” ในอนาคตเรามาพูดถึงประเด็นการตัดสินใจเกี่ยวกับการกำหนดค่าหลักสำหรับผู้ตรวจสอบความถูกต้องในวันนี้.

        ในการเรียกใช้หรือไม่เพื่อเรียกใช้ไคลเอ็นต์ Eth1?

        เป็นพิธีการที่ฉันพยายามให้นักเรียนฝึกหัดของเราให้บ่อยที่สุดเท่าที่จะทำได้นั่นคือการซิงค์ไคลเอนต์ Ethereum 1.0 เป็นความลับที่เปิดเผยว่าจริงๆแล้วการโฮสต์โหนด Ethereum 1.0 แบบ“ เต็ม” เป็นการกระทำด้วยความรักแทนที่จะเป็นวิธีแก้ปัญหา Dilemma ของ Prisoner ที่แข็งกระด้าง ต้องใส่เครื่องหมายคำพูด “เต็ม” เพราะแม้แต่นักพัฒนาหลักของ Ethereum ก็ยังมีช่วงเวลาที่ยากลำบากในการตกลงกันเรื่องคำจำกัดความว่า “โหนดเต็ม” หมายถึงอะไร.

        สิ่งหนึ่งที่เราเห็นพ้องต้องกัน: ต้องใช้เวลาและพื้นที่จัดเก็บมากกว่าในการซิงค์ไคลเอนต์ Ethereum 1.0 มากกว่าที่คุณคิด ผู้ตรวจสอบความถูกต้องของเราจำเป็นต้องมีวิธีสืบค้นฐานข้อมูลเครือข่าย Ethereum 1.0 (เราจะมาดูสาเหตุในภายหลัง) หากคุณต้องการประหยัดพื้นที่และปวดหัวในการซิงค์ในเครื่องคุณสามารถใช้ปลายทาง Infura, ซึ่งให้บริการฟรีเมื่อลงทะเบียน. 

        แม้ว่าสิ่งนี้จะช่วยประหยัดพื้นที่จัดเก็บและความกังวลด้านลอจิสติกส์ได้อย่างมาก แต่ก็ยังเสียสละการกระจายอำนาจจำนวนหนึ่งสำหรับเครือข่าย Eth1 และ Eth2 ไปพร้อม ๆ กัน ถ้า Infura ต้องลงไป, ซึ่งหายากมาก แต่เกิดขึ้น, ซึ่งจะทำให้เกิดการกระเพื่อมในตัวตรวจสอบ Ethereum 2.0 ที่ใช้มันสำหรับจุดสิ้นสุด Ethereum 1.0 สิ่งที่ต้องพิจารณา!

        (เพื่อให้ชัดเจน: ความยากในการซิงค์โหนดเต็ม Ethereum นั้นเกี่ยวข้องกับลักษณะของสถานะโลก Ethereum ไม่ใช่กับนักพัฒนาหลัก Ethereum 1.0 ที่ทำงานได้อย่างยอดเยี่ยมในการจัดการกับปัญหาที่ท้าทายอย่างยิ่งนี้)

        Virtual vs Local Hosting

        การพิจารณาครั้งต่อไปสำหรับฉันคือการโฮสต์โหนดตัวตรวจสอบความถูกต้องในเครื่อง (ในบ้านของฉัน) หรือแบบเสมือนจริง (บนผู้ให้บริการเสมือนเช่น Amazon Web Services (AWS), Digital Ocean เป็นต้น) ดังที่ฉันได้กล่าวไปแล้วในส่วนที่แล้วฉันไม่วางใจว่าตัวเองจะเรียกใช้โหนดตัวตรวจสอบความถูกต้องที่สอดคล้องกันจากที่บ้านแม้ในแล็ปท็อปเครื่องเก่าที่เก็บไว้ เงอะงะและโง่ฉันจะเตะมันหรือลืมมันไป.

        ฉันเลือกที่จะเรียกใช้โหนดของฉันบน AWS เพราะนั่นคือสิ่งที่ฉันคุ้นเคยมากที่สุด (หลังจากผ่านกระบวนการทั้งหมดนี้แล้วฉันคาดเดาการตัดสินใจครั้งนี้เป็นครั้งที่สองฉันจะพูดถึงเรื่องนี้ในภายหลัง) การแลกเปลี่ยนที่นี่คือการกระจายอำนาจอีกครั้ง: หาก AWS ล่มหรือมีปัญหาใด ๆ (เหมือนที่เพิ่งทำเมื่อไม่นานมานี้) ฉันอยู่ในความเมตตาของพวกเขา หากมีคนใช้งานโหนดบน AWS มากพออาจส่งผลกระทบต่อเครือข่าย Ethereum ที่มีขนาดใหญ่ขึ้น.

        ผู้คนอาจจะเลือกตัวเองสำหรับสิ่งนี้ โฮสติ้งในพื้นที่เป็นโครงการพิเศษและไม่ใช่ทุกคนที่มีเวลาทรัพยากรหรือความมุ่งมั่นที่จำเป็น ในขณะที่โฮสติ้งเสมือนเป็นการรวมศูนย์ แต่ฉันเลือกที่จะไปด้วยเนื่องจากใช้งานง่ายและ (หวังว่า) จะรับประกันความพร้อมในการทำงาน. 

        หากคุณต้องการเรียกใช้โหนดตัวตรวจสอบความถูกต้องในเครื่องคุณยังคงสามารถทำตามคำแนะนำทั่วไปของบทช่วยสอนนี้ได้, ชุดบทแนะนำที่ยอดเยี่ยมของ Somer Esat กับลูกค้าที่แตกต่างกัน หรือ แม้กระทั่งซิงค์ Raspberry Pi Model 4B กับ RAM 8GB กับ Ethereum บน ARM. (การซิงโครไนซ์ Raspberry Pi ยังอยู่ในขั้นทดลองและผู้คนควรรอจนกว่า Ethereum ในทีม ARM จะยืนยันความเสถียร)

        Eth2 Client Choice และการหลีกเลี่ยงบทลงโทษ

        อีกทางเลือกหลักคือไคลเอนต์ Ethereum 2.0 ในกลุ่มลูกค้าที่มีอยู่: ประภาคาร, ดาวหาง, Nimbus, Prysm และ Teku. ฉันมีความลำเอียงอย่างมากต่อ Teku และไม่เข้าใจเพียงพอที่จะถกเถียงประเด็นปลีกย่อยของลูกค้า. บทความนี้ เป็นภาพรวมที่ดีของประสิทธิภาพของลูกค้าใน Medalla (โปรดทราบว่า Medalla เรียกร้องอะไรจากโปรเซสเซอร์มากกว่าที่ mainnet จะทำได้)

        Proof of Stake ประกอบด้วยการไม่ตั้งใจอย่างชัดเจนเพื่อกระตุ้นให้เกิดพฤติกรรมที่ถูกต้องบนเครือข่าย สิ่งเหล่านี้อยู่ในรูปแบบของการกำหนดตัวตรวจสอบความถูกต้องสำหรับการออฟไลน์และการเคลื่อนไหวอย่างเจ็บแสบของนักแสดงเพื่อดำเนินการที่เป็นอันตรายต่อเครือข่ายไม่ว่าจะโดยเจตนาหรืออย่างอื่น.

        ปัญหาที่พบบ่อยที่สุดคือการตรวจสอบให้แน่ใจว่าเครื่องมือตรวจสอบของคุณพร้อมใช้งานในเครือข่าย ซึ่งหมายความว่าตรวจสอบให้แน่ใจว่าตัวตรวจสอบของคุณออนไลน์อยู่ มีแนวทาง DevOps สำหรับปัญหานี้คือการสร้างระบบตรวจสอบและแจ้งเตือนเพื่อแจ้งเตือนคุณหากตัวตรวจสอบของคุณออฟไลน์ฉันจะไม่กล่าวถึงในที่นี้.

        แต่มีอีกวิธีหนึ่งที่จะไม่สามารถใช้งานได้กับเครือข่ายนั่นคือถ้าลูกค้าของคุณเริ่มทำงานผิดปกติด้วยเหตุผลใดเหตุผลหนึ่ง หลังจาก ข้อผิดพลาดของเซิร์ฟเวอร์เวลา ทำให้เกิดการชะลอตัวของเครือข่ายบน Medalla นักพัฒนาหลักของ Eth2 จึงมาร่วมกันพัฒนา “ [a] รูปแบบมาตรฐานสำหรับการโอนประวัติการเซ็นชื่อของคีย์ช่วยให้ผู้ตรวจสอบความถูกต้องสามารถสลับไปมาระหว่างไคลเอนต์ได้อย่างง่ายดายโดยไม่ต้องเสี่ยงกับการลงนามในข้อความที่ขัดแย้งกัน” ไม่ใช่ลูกค้าทั้งหมดที่มีการป้องกันนี้ แต่ Teku มี ที่นี่คุณสามารถอ่านเกี่ยวกับการใช้ Teku’s Slash Protection (ทำงานตามค่าเริ่มต้น) รวมถึงการย้ายข้อมูลระหว่างโหนด Teku หรือโหนดที่ไม่ใช่ Teku ไปยัง Teku.

        หากคุณมีปัญหากับไคลเอนต์ของคุณและจำเป็นต้องรีสตาร์ทเครือข่ายทั้งหมดคุณต้องระวังเรื่องจุดอ่อน Proof of Work ช่วยให้ทุกคนสามารถย้อนกลับไปที่บล็อกการกำเนิดของเครือข่ายและสร้างสถานะเครือข่ายตั้งแต่เริ่มต้นได้อย่างน่าเชื่อถือ อย่างไรก็ตามการพิสูจน์การเดิมพันมีข้อสังเกต: หากหนึ่งในสามของตัวตรวจสอบความถูกต้องของเครือข่าย ณ จุดหนึ่งยังคงลงนามบล็อกและการรับรองต่อไปพวกเขาสามารถเปลี่ยนสถานะเครือข่ายและป้อนข้อมูลเท็จนั้นไปยังโหนดที่ซิงค์กับ เครือข่ายหากผู้ไม่ประสงค์ดีจับโหนดการซิงค์ก่อนที่โหนดการซิงค์จะไปถึงจุดที่ผู้ตรวจสอบความถูกต้องถอนเงินของตน คุณสามารถอ่านเพิ่มเติมได้ที่นี่ แต่คำตอบสั้น ๆ คือคุณต้องมี “จุดตรวจอัตนัยที่อ่อนแอ” หรือไฟล์สถานะที่เข้ารหัสซึ่งโดยพื้นฐานแล้วจะเป็นที่เก็บถาวรของเครือข่าย Teku จัดเตรียมแฟล็กเริ่มต้นสำหรับทั้งสองอย่าง.

        ข้อกังวลเรื่องบทลงโทษสุดท้ายที่ร้ายแรงที่สุด: การเจ็บแสบ ความเจ็บแสบเกิดขึ้นเมื่อสเตเกอร์ทำงานผิดกฎของเครือข่าย ซึ่งแตกต่างจากการถูกลงโทษจากการออฟไลน์ มีการทำงานอย่างแข็งขันกับเครือข่ายโดยการส่งข้อมูลตัวตรวจสอบที่ขัดแย้งกัน มีสื่อที่ยอดเยี่ยมสำหรับการเรียนรู้เพิ่มเติมเกี่ยวกับการเฉือนและวิธีป้องกัน:

        Takeaway หลักคืออย่าเรียกใช้คีย์ตัวตรวจสอบความถูกต้องเดียวกับไคลเอนต์หลายราย เห็นได้ชัดว่านี่คือสิ่งที่ทำให้เกิดเหตุการณ์เจ็บแสบครั้งแรก, ซึ่งเกิดขึ้นเมื่อวันที่ 2 ธ.ค.. มีการฟาดฟันกันหลายครั้งแล้ว! หากคุณกำลังย้ายข้อมูลจากอินสแตนซ์หนึ่งไปยังอีกอินสแตนซ์หนึ่งการตรวจสอบสี่ครั้งคุณจะไม่มีเครื่องสองเครื่องทำงานจากคีย์เดียวกัน:

        ป๊าเบนบอกเหมือนเลย. ที่มา

        ข้อกำหนดการกำหนดค่า AWS + Infura + Teku Validator

        การตั้งค่าบล็อก Genesis ของฉัน:

        ระบบปฏิบัติการ: เซิร์ฟเวอร์ Ubuntu 20.04 LTS (HVM) (Amazon Web Service)

        หน่วยประมวลผล: โปรเซสเซอร์ Intel Xeon Platinum 8000 series, 3.1 GHz (บริการเว็บ Amazon)

        หน่วยความจำ: 4 คอร์เสมือนจริง, RAM 16GB (Amazon Web Service)

        การจัดเก็บ: 100GB SSD, 300/3000 IOPS (Amazon Web Service)

        ไคลเอนต์ Ethereum 1.0: จุดสิ้นสุด Infura (ระดับฟรี)

        ไคลเอนต์ Ethereum 2.0: Teku

        เมื่อพิจารณาจากข้อควรพิจารณาทั้งหมดข้างต้นแล้วฉันไม่แน่ใจถึงแนวทางที่ดีที่สุดในการสร้างการตั้งค่าตัวตรวจสอบความถูกต้อง สำหรับตัวฉันเองฉันต้องการเลือกเครื่องและโดยทั่วไปไม่ต้องกังวลกับการเปลี่ยนเครื่องเป็นเวลาอย่างน้อยสองปี สิ่งนี้ช่วยเรื่องค่าใช้จ่ายในการตรวจสอบความถูกต้องโดยรวม (ฉันสามารถได้รับส่วนลดจำนวนมากจากการล็อกอินกับผู้ให้บริการเสมือนเป็นเวลาสองสามปี) และฉันไม่คล่องตัวเป็นพิเศษกับการหมุนเซิร์ฟเวอร์ การพิสูจน์อนาคตหรือแนวทาง“ เกินความจำเป็น” นี้หวังว่าจะทำให้ชีวิตของฉันในอีกสองปีข้างหน้าง่ายขึ้นเล็กน้อย.

        ในตอนแรกฉันมั่นใจว่า AWS เป็นแพลตฟอร์มเสมือนจริงที่ดีที่สุดและเป็นบริการที่ฉันจะใช้สำหรับโพสต์นี้และต่อไป อย่างไรก็ตามหลังจากผ่านขั้นตอนทั้งหมดแล้วฉันได้ตระหนักว่า AWS อาจใช้งานมากเกินไปสำหรับนักพัฒนาแต่ละราย ความแข็งแกร่งที่แท้จริงของ AWS ดูเหมือนจะเป็นความสามารถในการขยายขนาดแบบไดนามิกเพื่อตอบสนองความต้องการซึ่งมาพร้อมค่าใช้จ่ายระดับพรีเมียม สิ่งนี้มีความหมายทางเศรษฐกิจสำหรับโครงการขนาดใหญ่ระดับองค์กร แต่ Ethereum 2.0 แต่ละตัว ปัจจุบัน ความต้องการของลูกค้าไม่จำเป็นต้องมีความเข้มงวดเช่นนี้.

        ฉันกำลังจะดำเนินการต่อกับ AWS แต่ยังให้ความบันเทิงกับตัวเลือกในการเรียกใช้อินสแตนซ์บน Digital Ocean ซึ่งอาจเหมาะสมกว่าสำหรับนักพัฒนาแต่ละราย เพิ่มเติมในภายหลัง.

        ตั้งค่าบัญชี Infura

        ฉันกำลังเลือกใช้ Infura เป็นอุปกรณ์ปลายทาง Ethereum 1.0 สำหรับตอนนี้สายสัญญาณบีคอนกำลังดูสัญญาการฝากบน Ethereum 1.0 เพื่อเปิดใช้งาน stakers ใหม่เมื่อพวกเขาฝาก 32 ETH อย่างถูกต้องและส่งลายเซ็น BLS ที่เหมาะสม.

        ในอนาคตบีคอนเชนจะเริ่มทดสอบการประมวลผลเพิ่มเติมโดยเริ่มใช้ข้อมูลสถานะจาก Ethereum 1.0 เพื่อสร้างจุดตรวจคู่ขนานบนสายสัญญาณ.

        ดังที่เราได้กล่าวไว้ข้างต้นมีสองวิธีหลักในการมองเห็นเครือข่าย Ethereum 1.0 หนึ่งคือการซิงค์และดูแลโหนด Ethereum 1.0 ซึ่งสร้างฐานข้อมูลสถานะ Ethereum 1.0 ในเครื่อง อีกประการหนึ่งคือการใช้บริการเช่น Infura ซึ่งมีจุดสิ้นสุด Ethereum 1.0 ที่ใช้งานง่ายเข้าถึงได้ผ่าน HTTPS หรือ WebSockets.

        ลงชื่อเข้าใช้บัญชีที่นี่. เมื่อคุณมีบัญชีแล้วให้คลิกโลโก้ Ethereum ทางด้านซ้ายมือ.

        คลิก “สร้างโครงการใหม่” ที่มุมขวาบน

        ตั้งชื่อโปรเจ็กต์ของคุณ (ของฉันคือ“ Eth 2 Validator”) และไปที่“ การตั้งค่า” ตรวจสอบว่าปลายทางเครือข่ายของคุณคือ“ Mainnet” และคัดลอกปลายทาง HTTPS:

        เราจะใช้สิ่งนี้ในภายหลังสำหรับคำสั่งเริ่มต้นไคลเอนต์ Teku ของเรา!

        การตั้งค่าอินสแตนซ์ AWS

        การตั้งค่าอินสแตนซ์ EC2 บน Amazon นั้นตรงไปตรงมา เราจะมีการปรับแต่งเล็กน้อยที่นี่และที่นั่นเพื่อช่วยให้อินสแตนซ์เสมือนของเราเล่นกับ Teku ได้ดี.

        สร้างบัญชี AWS (แตกต่างจากบัญชี Amazon.com) และเข้าสู่ระบบ AWS Console ไปที่หน้า EC2 ซึ่งจะมีลักษณะดังนี้:

        คลิกปุ่ม“ Launch Instance” จากนั้นคุณจะเห็นหน้าจอต่อไปนี้:

        ระบบปฏิบัติการ

        นี่คือที่ที่เราเลือกอิมเมจของเครื่อง (ซึ่งฉันคิดว่าเป็นระบบปฏิบัติการ) ที่เราต้องการใช้บนอินสแตนซ์เสมือนของเรา ฉันกำลังเลือก Ubuntu Server 20.04 ซึ่งเป็นสภาพแวดล้อมเซิร์ฟเวอร์ที่ใช้ Linux สภาพแวดล้อมเซิร์ฟเวอร์ Ubuntu มีความแตกต่างในการปรับให้เหมาะสมที่สำคัญบางประการจากสภาพแวดล้อม Ubuntu Desktop ความแตกต่างหลักสำหรับวัตถุประสงค์ของเราคือเซิร์ฟเวอร์ Ubuntu ไม่มีส่วนต่อประสานผู้ใช้แบบกราฟิก (GUI) เราจะไปที่ไหนมี แต่บรรทัดคำสั่ง! นำฉันกลับสู่วัน Apple II ของฉัน.

        หลังจากเลือกระบบปฏิบัติการของเราแล้วเราก็เลือกประเภทอินสแตนซ์ของเรา:

        ฉันคิดว่าเมนูนี้ค่อนข้างล้นหลามดังนั้นฉันจะอธิบายให้คุณฟังเล็กน้อย ที่นี่เรากำลังเลือกแกนประมวลผล / พลังงาน RAM / CPU สำหรับเครื่องของเรา เป็นหน่วยความจำแบบ “ดิบ” หรือ “หน่วยความจำที่ใช้งานอยู่” ของเครื่องและแยกออกจากที่เก็บข้อมูล (ฮาร์ดไดรฟ์) ของอุปกรณ์ คิดว่ามันเป็นกลไกของอินสแตนซ์เสมือนของเราซึ่งเราจะเรียกใช้ระบบปฏิบัติการ Ubuntu Server ของเรา AWS แยกสิ่งเหล่านี้ออกเป็นกลุ่มอินสแตนซ์ที่แยกจากกันซึ่งแสดงโดยการผสมตัวอักษร / ตัวเลขในคอลัมน์ด้านซ้ายสุด.

        ตระกูลอินสแตนซ์มีการจัดเตรียมฮาร์ดแวร์ที่แตกต่างกันเช่นเดียวกับเครื่องยนต์ของรถยนต์ที่แตกต่างกันมีการกำหนดค่าลูกสูบปลั๊กและเชื้อเพลิงที่แตกต่างกันเพื่อตอบสนองความต้องการที่แตกต่างกัน เราจะเน้นไปที่ตระกูลอินสแตนซ์ “การคำนวณทั่วไป” สองตระกูล ได้แก่ m5 และ t3.

        ฉันกำลังเลือกอินสแตนซ์ m5.xlarge ซึ่งมี 4 แกนประมวลผลเสมือน (vCPU) และ RAM 16GB หลังจากเรียกใช้ Ethereum 2.0 mainnet เป็นเวลาหนึ่งวันเครื่องของฉันไม่ได้ใช้ vCPU เกิน 4% ที่มีอยู่ ดังที่ได้กล่าวไว้ในหัวข้อ“ Future Proofing” ข้างต้นความต้องการเครือข่าย Ethereum 2.0 จะเพิ่มขึ้นเท่านั้น แต่ในอีกไม่กี่เดือนข้างหน้าไม่มีการเพิ่มขึ้นอย่างรวดเร็วของเครือข่ายหลักที่ยืดเยื้อฉันน่าจะดีกับอินสแตนซ์ m5.large (2 คอร์เสมือน / vCPU, RAM 8GB)

        ผู้เชี่ยวชาญด้านเทคนิคที่เข้าใจมากกว่าตัวเองได้แนะนำอินสแตนซ์ t3.large เป็นตัวเลือกที่เหมาะสมสำหรับ Ethereum 2.0 t3.large มี 2 vCPU และหน่วยความจำ 8GB เช่นเดียวกับ m5.large แต่ตระกูล t3 ถูกสร้างขึ้นเพื่อกิจกรรมเครือข่ายที่ “มีสัญญาณรบกวน” มากขึ้น (spikes ใน CPU) มากกว่าตระกูล m5 ที่สร้างขึ้นสำหรับการโหลด CPU ที่สม่ำเสมอ.

        ราคา

        สิ่งสุดท้ายที่จะพูดถึงก่อนที่เราจะไปยังพื้นที่จัดเก็บคือราคา AWS มีราคาแพงเมื่อเทียบกับตัวเลือกอื่น ๆ เช่น Digital Ocean คุณจ่ายค่า CPU (ตระกูลอินสแตนซ์ของคุณ) และพื้นที่เก็บข้อมูล (ฮาร์ดไดรฟ์ของคุณ) แยกกันตามสิ่งที่คุณใช้ CPU จ่ายเป็นรายชั่วโมง เนื่องจากผู้ตรวจสอบความถูกต้องต้องออนไลน์ 24 ชั่วโมงคุณสามารถใช้ตารางราคาด้านล่าง (ตั้งแต่เดือนธันวาคม 2020) เพื่อทำการคำนวณคร่าวๆ: 

        ราคาเหล่านี้เป็นราคาตามความต้องการ AWS ให้สิ่งที่เรียกว่า ราคาอินสแตนซ์แบบจอง, โดยที่หากคุณสัญญาว่าจะมีอินสแตนซ์เสมือนตั้งแต่หนึ่งปีถึงสามปีคุณสามารถลดต้นทุนได้ถึง 50-60% จากตารางราคาด้านบน (ขอบคุณ Jason Chroman สำหรับเคล็ดลับนี้!)

        จากหน้าแรกของ EC2 คลิก “อินสแตนซ์แบบเหมาจ่าย” ที่เมนูด้านซ้ายมือที่แสดงด้านล่าง:

        คลิกที่ “ซื้ออินสแตนซ์แบบเหมาจ่าย”:

        ในเมนูที่ปรากฏขึ้นให้ใส่รายละเอียดประเภทอินสแตนซ์และระยะเวลาที่ต้องการดูราคาสำหรับ (ฉันกำลังเลือก m5.xlarge และระยะเวลา 36 เดือน):

        คลิก “ค้นหา” และดูตัวเลือกราคา:

        มีส่วนลดราคาจำนวนมากฉันเชื่อว่ามากกว่า 50% แต่ฉันถูกขังอยู่ในสามปี เมื่อคุณซื้ออินสแตนซ์แบบเหมาจ่ายแล้ว AWS จะนำไปใช้กับกล่องเสมือนที่มีอยู่หรือจะใช้งานทันทีที่เปิดใช้งาน โปรดจำไว้ว่าสิ่งนี้ไม่รวมถึงพื้นที่จัดเก็บข้อมูล (ฮาร์ดไดรฟ์). 

        หมายเหตุ: ฉันยังไม่ได้ดำเนินการดังกล่าวเนื่องจากฉันยังไม่มั่นใจว่า AWS เป็นตัวเลือกที่ดีที่สุดสำหรับแต่ละโหนดที่มีโหนดตรวจสอบความถูกต้อง Ethereum 2.0 หนึ่งถึงสามโหนด. ฉันกำลังเรียกใช้อินสแตนซ์ที่มีการกำหนดราคาตามความต้องการเพื่อดูว่ามันเป็นอย่างไรก่อนที่จะตกลง. 

        การจัดเก็บ

        ย้อนกลับไปที่กระบวนการเปิดใช้อินสแตนซ์ของเราเรากำลังไปที่แท็บ “เพิ่มพื้นที่เก็บข้อมูล”

        ผู้เชี่ยวชาญด้านเทคนิคที่ยอดเยี่ยมที่ฉันปรึกษาแนะนำให้ใช้พื้นที่จัดเก็บข้อมูลขนาด 100GB General Purpose SSD โดยทั่วไปพื้นที่จัดเก็บจะไม่เกิดปัญหาคอขวดกับไคลเอนต์ Eth2. อย่างไรก็ตามนี่คือ ไม่มี เรียกใช้ไคลเอ็นต์ Eth1 เต็มรูปแบบ. สำหรับพื้นที่จัดเก็บข้อมูล Eth1 ค่าคาดเดาแบบอนุรักษ์นิยมจะอยู่ที่ประมาณ 1TB อย่าลืมคำนึงถึงสิ่งนี้หากคุณไม่ได้ใช้ Infura.

        ฉันไม่รู้จักหน่วยในคอลัมน์ IOPS ในภาพด้านบน แต่เป็นอินพุตเอาต์พุตสำหรับฮาร์ดไดรฟ์ที่สื่อสารกับ CPU นี่คือคอขวดแบบคลาสสิกสำหรับการซิงค์โหนด Eth1 แบบเต็ม หากคุณต้องการซิงค์ไคลเอ็นต์ Eth1 แบบเต็มในเครื่องนี้และคุณกำลังมีปัญหานี่อาจเป็นจุดที่น่าค้นหา.

        พอร์ต

        การข้าม “เพิ่มแท็ก” ไปที่ “กำหนดค่ากลุ่มความปลอดภัย” นี่คือช่องเปิดต่างๆที่สร้างขึ้นสำหรับการสื่อสารขาเข้าและขาออกประเภทต่างๆกับอินสแตนซ์.

        AWS จะเปิดพอร์ต SSH แบบเดิมโดยอัตโนมัติซึ่งเป็นวิธีหลักที่เราจะโต้ตอบกับอินสแตนซ์. เม็ดมะม่วงหิมพานต์ และ Somer Esat’s คำแนะนำที่ยอดเยี่ยมทั้งสองแนะนำให้ปิดใช้งานการเข้าถึงรหัสผ่านสำหรับ SSH แต่เราจะเห็นเมื่อเราเปิดอินสแตนซ์ที่ไม่ใช่ตัวเลือกเริ่มต้นสำหรับ AWS อย่างไรก็ตามเป็นการดีที่จะสุ่มพอร์ต SSH ของคุณเป็นตัวเลขระหว่าง 1024-65535 นี่เป็นการป้องกันไม่ให้ผู้ไม่ประสงค์ดีสแกนเครือข่ายพอร์ต SSH มาตรฐาน ดูวิธีการรักษาความปลอดภัยพอร์ต SSH ของคุณโดยทั่วไป ที่นี่ และสำหรับ AWS โดยเฉพาะ ที่นี่.

        เราต้องเพิ่มกฎความปลอดภัยสองข้อเพื่อรองรับไคลเอนต์ Teku และเกี่ยวข้องกับการสื่อสารแบบเพียร์ทูเพียร์ เครือข่าย Blockchain มีการกระจายอำนาจในแง่ที่ว่าโหนดพูดคุยกันโดยตรง แทนที่จะปรึกษาโหนดกลางแต่ละโหนดจะพัฒนาและรักษาความเข้าใจเกี่ยวกับสถานะเครือข่ายโดยการ “นินทา” กับโหนดจำนวนมาก ซึ่งหมายความว่าเมื่อไคลเอนต์คนหนึ่งจับมือกับอีกคนหนึ่งพวกเขาจะแลกเปลี่ยนข้อมูลเกี่ยวกับเครือข่าย ทำครั้งเดียวพอกับโหนดที่แตกต่างกันข้อมูลจะแพร่กระจายไปทั่วเครือข่าย ปัจจุบันโหนด Eth2 Validator ของฉันมีเพื่อน 74 คนที่แชทอยู่.

        Teku สื่อสารกับโหนดอื่น ๆ บนพอร์ต 9000 ดังนั้นเราจะเปิดขึ้นสำหรับ UDP และ TCP, โปรโตคอลการสื่อสารสองประเภทที่แตกต่างกัน. 

        หลังจากนั้นควรมีลักษณะดังนี้:

        คีย์ SSH และการเปิดตัวอินสแตนซ์

        สุดท้ายไปที่ “ตรวจสอบและเปิดตัว” ภาพรวมของตัวเลือกที่เลือก เมื่อได้รับการอนุมัติจะมีเมนูป๊อปอัปเกี่ยวกับคีย์ SSH ฉันไม่ได้แสดงของฉันเนื่องจากมีข้อมูลที่ละเอียดอ่อน กล่าวคือคีย์คู่ที่ใช้ในการพิสูจน์ตัวตนและล็อกอินเข้าสู่อินสแตนซ์เสมือนผ่าน SSH (บรรทัดคำสั่งภายใน) หากคุณยังไม่มีคู่ AWS จะสร้างคู่ให้คุณ. คุณต้องดาวน์โหลดและปฏิบัติเหมือนคีย์ส่วนตัว Ethereum! เป็นวิธีเดียวที่จะเชื่อมต่อกับอินสแตนซ์ของคุณและ AWS จะไม่บันทึกไว้ให้คุณ.

        เมื่อทุกอย่างเป็นแบบ hunky-dory แล้วหน้าต่างนี้จะปรากฏขึ้น:

        ตกลง! เสร็จแล้วเรามาดูการเข้าถึงและรักษาความปลอดภัยอินสแตนซ์ของเราจากนั้นติดตั้งและเรียกใช้ 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 ไปยังอินสแตนซ์เสมือนของเรา Secure Copy Protocol (scp) ช่วยให้เราทำสิ่งนี้ได้อย่างปลอดภัย ปรับคำสั่ง scp ทั่วไปด้านล่างโดยใช้พา ธ ไปยังไดเร็กทอรีด้านบนและคำสั่ง SSH ก่อนหน้า:

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [ป้องกันอีเมล]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (สังเกต“: ~” ที่ท้ายคำสั่งทั้งหมด)

        คุณควรเห็นการถ่ายโอนไฟล์เกิดขึ้น หากคุณย้อนกลับไปที่เซสชัน SSH ของคุณและพิมพ์ ls คุณจะเห็นไดเร็กทอรีที่ถ่ายโอน.

        การติดตั้ง Teku

        ตอนนี้เรามีไฟล์ validator ที่ต้องการแล้วเรากำลังจะติดตั้ง Teku ก่อนอื่นเราต้องอัปเดตโปรแกรมที่มีอยู่และติดตั้งระบบ Java ที่จำเป็น:

        ติดตั้ง Java

        อัปเดต sudo apt && sudo apt ติดตั้ง default-jre && sudo apt ติดตั้ง default-jdk

        ตรวจสอบอีกครั้งว่า Java ติดตั้งสำเร็จด้วย:

        java – เวอร์ชัน

        ติดตั้งไบนารี

        ค้นหา 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 / ├── LICENSE ├── 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

        สร้างผู้ใช้ที่ไม่ใช่รูท

        ขั้นตอนนี้คัดลอกมาจาก Somer Esat’s การสอน Ubuntu / Teku ที่ยอดเยี่ยม

        เรากำลังจะสร้างผู้ใช้ที่ไม่ใช่รูทชื่อ 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 การสอน Ubuntu / Teku ที่ยอดเยี่ยม

        ขั้นตอนนี้จะสร้างบริการที่จะเรียกใช้ Teku ในพื้นหลัง นอกจากนี้ยังอนุญาตให้เครื่องรีสตาร์ทบริการโดยอัตโนมัติหากเครื่องหยุดทำงานด้วยเหตุผลบางประการ นี่เป็นขั้นตอนที่จำเป็นเพื่อให้แน่ใจว่าโปรแกรมตรวจสอบของเราทำงาน 24-7.

        สร้างไฟล์บริการโดยใช้โปรแกรมแก้ไขข้อความนาโน:

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

        ในไฟล์นี้ (ซึ่งควรว่างเปล่า) เราจะใส่ชุดคำสั่งเพื่อให้ systemd ดำเนินการเมื่อเราเริ่มบริการ รหัสด้านล่างนี้คุณจะต้องย่อยในรายการต่อไปนี้ที่เรารวบรวมไว้ตลอดการเดินทางนี้:

        • Infura Eth1 HTTP Endpoint
        • เส้นทางไดเร็กทอรี validator_key_info พร้อมไฟล์ที่เกี่ยวข้องกับคีย์ที่ถูกต้องสองไฟล์
        • เส้นทางข้อมูลที่กำหนดเอง (lib / var / teku)

        ใส่ค่าเหล่านั้นในโค้ดตัวหนาด้านล่างจากนั้นคัดลอกทั้งหมดลงในโปรแกรมแก้ไขข้อความนาโน:

        [Unit] Description = Teku Beacon Node ต้องการ = 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/KEY123STORE-M_123456_789_ABCD.json: /home/ubuntu/validator_key_info/validator_keys/KEY123STORE-M_123456_789_ABCD.json –rest-api-enable = true –rest-api-docs-enable = true –metrics-enabled –validators-keystore-locking-enabled = false –ข้อมูลฐานเส้นทาง = / var / lib / teku [ติดตั้ง] WantedBy = multi-user.target

        พิมพ์ command-X จากนั้นพิมพ์ “Y” เพื่อบันทึกการเปลี่ยนแปลงของคุณ

        เราต้องรีสตาร์ท“ systemctl” เพื่ออัปเดต:

        sudo systemctl daemon-reload

        เริ่มบริการ:

        sudo systemctl เริ่ม teku

        ตรวจสอบให้แน่ใจว่าเริ่มต้นได้ดี:

        sudo systemctl สถานะ teku

        หากคุณพบข้อผิดพลาดรับรายละเอียดเพิ่มเติมโดยเรียกใช้:

        sudo journalctl -f -u teku.service

        คุณสามารถหยุดบริการ Teku ได้โดยเรียกใช้:

        sudo systemctl หยุด teku

        ตรวจสอบหน้าการแก้ไขปัญหา Teku สำหรับข้อผิดพลาดทั่วไปหรือ ตรวจสอบความไม่ลงรอยกันของ Teku, ซึ่งได้รับการตรวจสอบโดยทีมงาน.

        เมื่อคุณรู้สึกว่าคุณมีสิ่งต่าง ๆ ออกไปแล้วให้เปิดใช้งานบริการเพื่อเริ่มต้นใหม่หากปิดตัวลงโดยการเรียกใช้:

        sudo systemctl เปิดใช้งาน teku

        มีแล้ว! สิ่งที่ควรทำในขณะนี้ เมื่อตรวจสอบบริการ Teku คุณจะเห็นชุดของบันทึกที่ระบุเหตุการณ์การซิงค์ซึ่งเป็นเครื่องมือตรวจสอบของคุณที่ซิงค์ห่วงโซ่บีคอน เมื่อถึงส่วนหัวแล้วบันทึกเหล่านั้นจะเปลี่ยนเป็นอ่านเหตุการณ์ของช่องและคุณจะเห็นประสิทธิภาพการยืนยันและข้อเสนอบล็อกของคุณด้วย.

        เปิด

        ที่มา: Beaconcha.in

        ในวันที่ 1 ธันวาคมเวลา 12.00 น. UTC บล็อกแรกของ Beacon Chain ได้รับการตรวจสอบความถูกต้อง บล็อกแรกมาจาก ผู้ตรวจสอบความถูกต้อง 19026, ด้วยกราฟฟิตีที่น่าฉงน“ นาย F อยู่ที่นี่แล้ว” สิบสองวินาทีต่อมาบล็อกถัดไปกราฟฟิตีบ่งชี้ว่าตัวตรวจสอบความถูกต้องอาจอยู่ใน ซุกสวิตเซอร์แลนด์. Eth2 Beacon Chain เพิ่มขึ้นเรื่อย ๆ บล็อกทีละบล็อกทุกๆ 12 วินาที จากนั้นอุปสรรคต่อไปก็มาถึง: ผู้ตรวจสอบความถูกต้องเพียงพอที่จะออนไลน์เพื่อสรุปยุคแรกหรือไม่? ใช่ ผู้ตรวจสอบความถูกต้อง 82.27% ยืนยันถึงความถูกต้องของยุค 0 ซึ่งเป็นชั้นล่างของ Beacon Chain ที่เป็นที่เลื่องลือ คุณสามารถอ่านเพิ่มเติมเกี่ยวกับการเปิดตัว Beacon Chain และสิ่งต่อไปได้ที่นี่. 

        ที่มา: Beaconcha.in

        ตอนนี้เราอยู่ที่ Epoch 760 ซึ่งหมายความว่า Beacon Chain ทำงานได้อย่างราบรื่นมาเกือบหนึ่งสัปดาห์แล้ว. 

        นี่คือภาพจากมุมมองของฉันเกี่ยวกับช่วงเวลาแห่งการกำเนิดโดยใช้การตั้งค่าที่อธิบายไว้ในโพสต์นี้:

        ในตอนต่อไปเราจะสรุปว่าสิ่งต่างๆเป็นอย่างไร ฉันจะเข้าถึงเมตริกจาก Teku พูดคุยเกี่ยวกับค่าใช้จ่ายในการเรียกใช้ AWS และพูดคุยสั้น ๆ เกี่ยวกับสถานะของเครือข่าย.

        คอยติดตาม!

        แหล่งข้อมูลและลิงค์

        ขอขอบคุณ 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 และ Alex Tudorache สำหรับการสนับสนุนและความช่วยเหลือด้านเทคนิค.

        Ethereum 2.0 จดหมายข่าวสมัครรับจดหมายข่าวของเราเพื่อรับข่าวสารล่าสุดเกี่ยวกับ Ethereum โซลูชันระดับองค์กรทรัพยากรสำหรับนักพัฒนาและอื่น ๆ ที่อยู่อีเมล

        Mike Owergreen Administrator
        Sorry! The Author has not filled his profile.
        follow me