Ethereum 2.0에서 검증자가되기위한 나의 여정, 2 부

블로그 1뉴스 개발자 엔터프라이즈 블록 체인 설명 이벤트 및 컨퍼런스 보도 자료뉴스 레터

뉴스 레터 구독.

이메일 주소

우리는 귀하의 개인 정보를 존중합니다

홈 블로그 개발자

Ethereum 2.0에서 검증자가되기위한 나의 여정, 2 부

Ethereum 2.0 유효성 검사기 클라이언트를 실행하기 위해 하드웨어와 소프트웨어를 선택할 때 고려해야 할 사항은 무엇입니까? by Coogan Brennan 2020 년 12 월 5 일 Posted on December 5, 2020

이더 리움 2에서 검증자가되기위한 나의 여정 2 부

참고 : 이더 리움 2.0 네트워크에서 검증자가 될 수 있습니다! 유효성 검사기로 활성화되는 대기 시간이 있습니다. 2020 년 12 월 4 일 현재 대기 시간은 대략입니다. 9.9 일. 이 시리즈의 1 부에서 스테이 킹 단계를 확인하세요..

  1. 부인 성명
  2. 소개
  3. 유효성 검사기 구성 고려 사항
  1. 미래 보장 하드웨어
  2. Eth1 클라이언트를 실행하거나 실행하지 않으려면?
  3. 가상 대 로컬 호스팅
  4. Eth2 클라이언트 선택 및 처벌 방지
  • AWS 인스턴스 설정
    1. 운영 체제
    2. 가격
    3. 저장
    4. 항구
    5. SSH 키 및 인스턴스 시작
    6. Teku 설치
      1. 요구 사항
      2. 바이너리 설치
      3. 루트가 아닌 사용자 만들기
      4. systemd 서비스 생성
      5. 시작하다
      6. 부인 성명

        이것은 ConsenSys의 직원이자 비콘 체인에 스테이 킹을 계획중인 사람으로 작성하고있는 게시물입니다. 이전 진술은 내가 ConsenSys 제품의 우선 순위를 지정한다는 것을 의미합니다 (ConsenSys 제품은 일반적으로 이더 리움에서 동급 최고이며 질문에 답하고 문제 해결을 도와 줄 엔지니어링 팀에 액세스 할 수 있습니다). 후자의 진술은 비용과 사용 편의성을 위해 최적화하고 있음을 의미합니다. 상당한 보상을 얻을 수있는 수천 개의 ETH가 없으므로 지름길을 택하고 있습니다. 이것은 내가 Ethereum 2.0에 대한 스테이 킹을 가능한 한 간단하고 개인이 접근 할 수 있도록하기 위해 내린 결정이지만 탈 중앙화 및 개인 정보 보호에 대한 절충안이 따릅니다. 그러나 아래 튜토리얼의 광범위한 스트로크를 따라 다른 선택을 할 수 있습니다. 사실, 그렇게 할 수 있다면! 

        마지막으로, Ethereum 2.0에서의 스테이 킹은 매우 실험적이며 장기적인 노력이 필요합니다 (3 년 할당). 아직 개발중인 높은 수준의 리스크 수행자에게 불편한 경우 참여하지 마십시오. 스테이 킹을해야하는지 확실하지 않다면 ConsenSys 불일치 # teku-public 채널에서 물어보세요. 

        소개

        이전 게시물에서 우리는 Ethereum 2.0의 배포 이유를 논의하고 Ethereum 1.0 메인 넷 입금 계약에서 32 ETH를 스테이 킹하는 과정을 살펴 보았습니다. 우리는 키 생성과 스테이 킹 프로세스에 대해 발사대 이더 리움 1.0에서 2.0으로 연결.

        11 월 23 일, 이더 리움 2.0 출시를위한 최소 스테이 킹 ETH 금액 (약 524,288)이 충족되었습니다. 사람들은 계약에 계속 지분을 가질 수 있으며 12 월 4 일 현재 검증 인 수가 33,000 명 이상으로 증가했습니다..

        MetaMask의 Aaron Davis가 내부 ConsenSys Slack 스테이 킹 채널에서 자신의 생각을 공유합니다. 

        검증 자로서 Genesis 블록에 포함되는 것은 매우 흥미로 웠지만 몇 초 후 내부 ConsenSys 스테이 킹 채널에서 동료 Aaron Davis와 비슷한 경험을했습니다. 내가 어떤 미친 작업에 등록 했습니까? 운 좋게도 저는이 루비에게 스테이 킹 인프라 운영에 대한 몇 가지 팁, 조언 및 통찰력을 제공 할 수있을만큼 자선적인 믿을 수 없을 정도로 뛰어난 기술 인력과 접근 할 수 있습니다. 이 귀중한 조언의 일부를 다른 이해 관계자들에게 전달하고 싶습니다..


        이것이이 기사의 첫 번째 부분입니다. Ethereum 2.0 유효성 검사기 클라이언트를 실행하기 위해 하드웨어와 소프트웨어를 선택할 때 고려해야 할 사항은 무엇입니까? 두 번째 부분에서는 유효성 검사기 클라이언트에 대해 선택한 특정 하드웨어 / 소프트웨어 조합을 살펴볼 것입니다. 구성에 대한 선택은 리소스, 개인적 성향 및 기술 능력에 따라 달라집니다. 개인적 편견과 상황이 내 선택에 어떻게 영향을 미쳤는지 강조하기 위해 최선을 다하겠습니다..

        마지막으로, 우리가 그것에 뛰어 들기 전에, 나는이 포스트들이 32 ETH를 스테이 킹 한 경험에 대한 저널 항목과 거의 비슷하다는 것을 반복하고 싶습니다. 따라서 비콘 체인이 진행됨에 따라 접근 방식을 약간 변경할 수 있습니다. 예를 들어, 저는 확실히 AWS를 사용할 것이라고 생각했습니다. 아래에서 읽으시 겠지만, 저는 지금 그것을 재고하고 있습니다. 나는 또한 스테이 킹의 재정적 요소에 대해서도 매우 분명하게 말할 것입니다. 스테이 킹은 이더 리움 생태계를 지원하는 방법이지만 지속 가능한 대중 사용을 위해서는 ETH를 보유한 사람들이 접근 할 수 있고 가능해야합니다.. 

        미래 보장 하드웨어

        오늘날 유효성 검사기를 실행하기위한 기본 요구 사항은 비교적 쉽게 충족 할 수 있습니다. Mara Schmiedt 및 Collin Meyers 유효성 검사기 가이드 on Bankless에는 최소 요구 사항에 대한 좋은 요약이 있습니다. Ethereum 2.0 검증 장비를 결정하는 가장 어려운 부분은 개발이 계속됨에 따라 현재 비콘 체인 단계 0의 현재 요구 사항과 현재 알려지지 않은 미래 요구 사항의 균형을 맞추는 것입니다. (검증 인을 면밀히 주시하고 변경 사항을 빠르고 쉽게 해결할 수 있다면 이는 문제가되지 않습니다.) 

        Ben Edgington, Teku 프로젝트 관리자 및 게시자 Eth2.news, 네트워크가 더 많은 유효성 검사기 클라이언트를 요구할 수있는 몇 가지 엣지 케이스를 제공했습니다. 단기적으로 가장 큰 관심사는 Medalla 시간 서버 사건, Prysm 클라이언트의 버그 및 후속 수정으로 인해 테스트 넷에서 마무리가 중단되었습니다 (대략적으로 네트워크에서 “블록을 생성”할 수 없음). 네트워크에 최종성이 없었기 때문에 ( “확인 된 블록”이 없음) 유효성 검사자는 RAM에 평소보다 더 많은 트랜잭션을 보유해야했습니다.. 

        8GB RAM (일반적인 상황에서는 충분할 수 있음)이있는 시스템에서 “메모리 부족”문제가 발생하여 슬래 싱이 발생할 수 있습니다. 이와 같은 급증은 드물지만 Phase 0 메인 넷에서는 문제가되지 않습니다..

        네트워크의 향후 구성 모호성은 Ethereum 1.0 및 2.0의 병합과 샤딩 도입입니다. 이러한 병합이 언제 발생하는지 또는 정확히 무엇이 필요한지 아직 알 수 없습니다. 강력한 CPU 백본이 0 단계 (가상 코어 4 개, 100GB SSD가있는 16GB RAM)로 이동 한 다음 저장 공간에 대한 향후 조정에주의를 집중하고 싶습니다. 이것은 과도한 것으로 판명되어 스테이 킹 보상을 먹을 수 있습니다..

        이것이 미래의 “알려진 알려지지 않은 사항”입니다. 오늘 검증 인을위한 주요 구성 결정 사항에 대해 논의하겠습니다..

        Eth1 클라이언트를 실행하거나 실행하지 않으려면?

        저는 부트 캠프 학생들에게 가능한 한 자주 이더 리움 1.0 클라이언트를 동기화하도록하는 통과 의례입니다. 실제로 “완전한”Ethereum 1.0 노드를 호스팅하는 것이 강화 된 죄수의 딜레마 솔루션이 아니라 사랑의 행위라는 것은 공개적인 비밀입니다. Ethereum 핵심 개발자조차도 “전체 노드”가 실제로 의미하는 바에 대한 정의에 동의하는 데 어려움을 겪기 때문에 “전체”는 따옴표로 묶어야합니다..

        우리 모두가 동의 할 수있는 한 가지 : Ethereum 1.0 클라이언트를 동기화하는 데는 생각보다 더 많은 시간과 스토리지가 필요합니다. 검증 인은 Ethereum 1.0 네트워크 데이터베이스를 쿼리하는 방법이 있어야합니다 (이유는 나중에 설명하겠습니다). 로컬 동기화의 공간과 골칫거리를 절약하고 싶다면 Infura 엔드 포인트를 사용할 수 있습니다., 등록시 무료로 제공됩니다.. 

        이는 상당한 저장 및 물류 문제를 줄여 주지만 Eth1 및 Eth2 네트워크에 대한 일정량의 탈 중앙화를 동시에 희생합니다. 인 푸라가 추락한다면, 매우 드물지만 발생합니다, 이는 Ethereum 1.0 엔드 포인트에이를 사용하는 Ethereum 2.0 검증 자 전체에 파급 효과를 유발합니다. 고려해야 할 사항!

        (명확하게 말하면, 이더 리움 풀 노드 동기화의 어려움은이 극도로 까다로운 문제를 처리해 온 이더 리움 1.0 코어 개발자가 아니라 이더 리움 세계 상태의 특성과 관련이 있습니다.)

        가상 대 로컬 호스팅

        다음으로 고려할 사항은 로컬 (내 집) 또는 가상 (AWS (Amazon Web Services), Digital Ocean 등과 같은 가상 서비스 제공 업체)에서 검증 자 노드를 호스팅하는 것이 었습니다. 이전 기사에서 언급했듯이 어딘가에 보관 된 오래된 랩톱에서도 집에서 일관된 유효성 검사기 노드를 실행한다고 믿지 않습니다. 서투르고 멍청 해 걷어차거나 잊어 버릴거야.

        저는 AWS에서 노드를 실행하기로 결정했습니다. 이것이 제가 가장 잘 알고있는 것이기 때문입니다 (그러나이 전체 프로세스를 수행 한 후이 결정을 두 번째로 추측하고 있습니다. 나중에 논의 할 것입니다). 여기서 절충점은 다시 분산화입니다. AWS가 다운되거나 문제가있는 경우 (최근처럼), 나는 그들의 자비에있다. 충분한 사람이 AWS에서 노드를 실행하면 더 큰 Ethereum 네트워크에 영향을 미칠 수 있습니다..

        사람들은 아마도 이것을 스스로 선택할 것입니다. 로컬 호스팅은 특별한 종류의 프로젝트이며 모든 사람이 필요한 시간, 리소스 또는 헌신을 가지고있는 것은 아닙니다. 가상 호스팅은 중앙 집중화의 힘이지만 사용 편의성과 (희망적으로) 가동 시간을 보장하기 때문에 사용하기로 결정했습니다.. 

        유효성 검사기 노드를 로컬에서 실행하려는 경우에도이 자습서의 일반적인 지침을 따를 수 있습니다., 다른 클라이언트를 대상으로 한 Somer Esat의 훌륭한 자습서 시리즈 또는 Raspberry Pi Model 4B를 8GB RAM과 Ethereum on ARM과 동기화. (라즈베리 파이에서의 동기화는 여전히 실험적이며 ARM 팀의 이더 리움이 안정성을 확인할 때까지 기다려야합니다)

        Eth2 클라이언트 선택 및 처벌 방지

        또 다른 주요 선택은 기존 클라이언트 중 Ethereum 2.0 클라이언트입니다. 등대, 길잡이 별, 후광, PrysmTeku. 나는 Teku에 크게 편향되어 있으며 클라이언트의 세부 사항에 대해 토론 할 정도로 정통하지 않습니다.. 이 기사 Medalla의 클라이언트 성능에 대한 적절한 개요입니다. (메달 라가 메인 넷보다 프로세서에 더 많은 것을 요구했다는 점을 명심하십시오.)

        Proof of Stake는 네트워크에서 올바른 행동을 장려하기 위해 명시적인 비 인센티브를 포함합니다. 이들은 오프라인 상태에 대한 dinging validator의 형태를 취하고 의도적으로 또는 다른 방식으로 네트워크에 대한 악의적 인 행동을 취하기 위해 행위자를 슬래 싱하는보다 극적인 움직임을 취합니다..

        가장 일반적인 문제는 유효성 검사기를 네트워크에서 사용할 수 있는지 확인하는 것입니다. 이것은 검증 인이 온라인 상태인지 확인하는 것을 의미합니다. 이 문제에 대한 DevOps 접근 방식이 있습니다. 유효성 검사기가 오프라인 상태가되면 경고하는 모니터링 및 경고 시스템을 만드는 것입니다. 여기서는 다루지 않겠습니다..

        그러나 네트워크에서 사용할 수없는 또 다른 방법이 있습니다. 즉, 클라이언트가 어떤 이유로 오작동을 시작하는 경우입니다. 후 시간 서버 버그 Medalla에서 네트워크 속도 저하를 일으켰고 Eth2 핵심 개발자가 함께 모여 “[a] 키의 서명 기록을 전송하기위한 표준 형식을 사용하면 검증자가 충돌하는 메시지에 서명 할 위험없이 클라이언트간에 쉽게 전환 할 수 있습니다.” 모든 클라이언트가 이러한 보호를받는 것은 아니지만 Teku는 있습니다. Teku 노드 간 또는 비 Teku 노드 간 마이그레이션을 포함하여 Teku의 슬래시 보호 (기본적으로 실행 됨) 사용에 대해 읽을 수있는 곳입니다..

        클라이언트에 문제가 있고 전체 네트워크를 다시 시작해야하는 경우 약한 주관성을 알고 있어야합니다. 작업 증명을 통해 누구나 네트워크의 제네시스 블록으로 돌아가서 처음부터 신뢰없이 네트워크 상태를 구축 할 수 있습니다. 그러나 지분 증명은 그 점에서 문제가 있습니다. 특정 지점의 네트워크 검증 자 중 1/3이 계속해서 블록 및 증명에 서명하면 네트워크 상태를 변경하고 해당 잘못된 데이터를 노드에 동기화 할 수 있습니다. 동기화 노드가 유효성 검사자가 자금을 인출 한 위치에 도달하기 전에 악의적 인 행위자가 동기화 노드를 포착하는 경우 네트워크. 여기에서 자세한 내용을 읽을 수 있지만 짧은 대답은 “약한 주관성 체크 포인트”또는 인코딩 된 상태 파일 (기본적으로 네트워크 아카이브)이 필요하다는 것입니다. Teku는 두 가지 모두에 대한 시작 플래그를 제공합니다..

        마지막 페널티 문제는 가장 심각한 문제입니다. 슬래 싱은 스테이 커가 네트워크 규칙을 위반할 때 발생합니다. 오프라인에서 벌점을받는 것과는 다릅니다. 상충되는 검증 인 정보를 제출하여 네트워크에 적극적으로 대응하고 있습니다. 슬래 싱과이를 방지하는 방법에 대해 자세히 알아볼 수있는 정말 훌륭한 자료가 있습니다.

        주요 요점은 여러 클라이언트에서 하나의 유효성 검사기 키를 실행하지 않는 것입니다. 분명히 이것이 최초의 슬래 싱 이벤트를 일으킨 원인입니다., 12 월 2 일에 발생한. 그 이후로 많은 슬래 싱이있었습니다! 한 인스턴스에서 다른 인스턴스로 마이그레이션하는 경우 동일한 키에서 작동하는 두 대의 머신이 없는지 네 번 확인합니다.

        Papa Ben은 그대로 말합니다.. 출처

        AWS + Infura + Teku Validator 구성 사양

        내 Genesis 블록 설정 :

        운영 체제 : Ubuntu Server 20.04 LTS (HVM) (Amazon 웹 서비스)

        프로세서 : Intel Xeon Platinum 8000 시리즈 프로세서, 3.1GHz. (Amazon 웹 서비스)

        기억: 4 개의 가상 코어, 16GB RAM (Amazon Web Service)

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

        Ethereum 1.0 클라이언트 : Infura 엔드 포인트 (프리 티어)

        이더 리움 2.0 클라이언트 : Teku

        위의 모든 고려 사항을 살펴보면 유효성 검사기 설정을 구축하는 가장 좋은 방법이 확실하지 않았습니다. 나 자신을 위해 기계를 선택하고 싶습니다. 일반적으로 최소 2 년 동안은 기계 교체에 대해 걱정하지 않습니다. 이는 전체 검증 자 비용을 줄이는 데 도움이되며 (몇 년 동안 가상 공급자를 사용하면 상당한 할인을받을 수 있습니다.) 서버 가동에 특히 민첩하지 않습니다. 이 미래 보장 또는 “과도한 사양”접근 방식은 향후 2 년 동안의 내 삶을 좀 더 쉽게 만들어 줄 것입니다..

        처음에는 AWS가 최고의 가상 플랫폼이며이 게시물과 다음 게시물에서 사용할 서비스라고 확신했습니다. 그러나 전체 프로세스를 거친 후 AWS가 개별 개발자에게 과잉 일 수 있음을 깨달았습니다. AWS의 진정한 강점은 프리미엄 비용으로 발생하는 수요를 충족하기 위해 동적으로 확장 할 수있는 능력입니다. 이것은 대규모 엔터프라이즈 수준 프로젝트에 경제적으로 합리적이지만 개별 Ethereum 2.0 흐름 클라이언트 요구 사항에는 이러한 엄격함이 필요하지 않습니다..

        AWS를 계속 사용할 예정이지만 개별 개발자에게 더 적합 할 수있는 Digital Ocean에서 인스턴스를 실행할 수도 있습니다. 나중에 더 자세히.

        Infura 계정 설정

        Infura를 Ethereum 1.0 엔드 포인트로 사용하기로 선택했습니다. 현재 비콘 체인은 32 개의 ETH를 적절하게 입금하고 적절한 BLS 서명을 제출했을 때 새로운 스테이 커를 활성화하기 위해 이더 리움 1.0에서 입금 계약을 지켜보고 있습니다..

        앞으로 비콘 체인은 비콘 체인에 병렬 체크 포인트를 생성하기 위해 이더 리움 1.0의 상태 정보를 사용하기 시작하여 추가 처리 테스트를 시작할 것입니다..

        위에서 언급했듯이 Ethereum 1.0 네트워크에 대한 가시성을 확보하는 두 가지 주요 방법이 있습니다. 하나는 로컬 Ethereum 1.0 상태 데이터베이스를 생성하는 Ethereum 1.0 노드를 동기화하고 적극적으로 유지하는 것입니다. 다른 하나는 HTTPS를 통해 액세스 할 수있는 간편한 Ethereum 1.0 엔드 포인트를 제공하는 Infura와 같은 서비스를 사용하는 것입니다. WebSockets.

        여기에서 계정에 서명. 계정이 있으면 왼쪽에있는 Ethereum 로고를 클릭하십시오..

        오른쪽 상단에있는 “새 프로젝트 만들기”를 클릭합니다.

        프로젝트의 이름을 지정하고 (내는 “Eth 2 Validator”임) “설정”으로 이동하여 네트워크 엔드 포인트가 “메인 넷”인지 확인하고 HTTPS 엔드 포인트를 복사합니다.

        나중에 Teku 클라이언트 시작 명령에 사용합니다.!

        AWS 인스턴스 설정

        Amazon에서 EC2 인스턴스를 설정하는 것은 간단합니다. 가상 인스턴스가 Teku와 잘 작동하도록 여기저기서 약간의 조정이있을 것입니다..

        AWS 계정 (Amazon.com 계정과 다름)을 생성하고 AWS 콘솔에 로그인합니다. 다음과 같은 EC2 페이지로 이동합니다.

        “인스턴스 시작”버튼을 클릭합니다. 그러면 다음 화면이 표시됩니다.

        운영 체제

        여기에서 가상 인스턴스에서 사용할 머신 이미지 (운영 체제라고 생각하는)를 선택합니다. Linux 기반 서버 환경 인 Ubuntu Server 20.04를 선택합니다. Ubuntu Server 환경에는 Ubuntu Desktop 환경과 몇 가지 주요 최적화 차이점이 있습니다. 우리 목적의 주요 차이점은 Ubuntu Server에는 그래픽 사용자 인터페이스 (GUI)가 없다는 것입니다. 우리가가는 곳은 명령 줄뿐입니다! Apple II 시절로 돌아갑니다..

        운영 체제를 선택한 후 인스턴스 유형을 선택합니다.

        이 메뉴가 너무 부담스러워서 좀 더 자세히 설명하겠습니다. 여기에서는 컴퓨터의 컴퓨팅 코어 / RAM 전력 / CPU를 선택합니다. 시스템의 “원시”또는 “활성 메모리”이며 장치의 저장소 (하드 드라이브)와는 별개입니다. Ubuntu Server 운영 체제를 실행할 가상 인스턴스의 엔진으로 생각하십시오. AWS는이를 맨 왼쪽 열의 문자 / 숫자 조합으로 표시된 별도의 인스턴스 패밀리로 분리합니다..

        인스턴스 제품군은 서로 다른 요구 사항을 충족하기 위해 서로 다른 자동차 엔진의 피스톤, 플러그 및 연료 구성이 서로 다른 것처럼 하드웨어 배열이 서로 다릅니다. 두 가지 “일반 계산”인스턴스 패밀리 인 m5 및 t3에 초점을 맞출 것입니다..

        4 개의 가상 컴퓨팅 코어 (vCPU)와 16GB RAM을 제공하는 m5.xlarge 인스턴스를 선택합니다. Ethereum 2.0 메인 넷을 하루 정도 실행 한 후 내 컴퓨터에서 사용 가능한 vCPU의 4 % 이상을 사용하지 않았습니다. 위의 “미래 보장”섹션에서 언급했듯이 Ethereum 2.0 네트워크 수요는 증가 할 것입니다. 그러나 향후 몇 달 동안은 장기간의 주요 네트워크 스파이크가 없으면 m5.large 인스턴스 (가상 코어 2 개 / vCPU, 8GB RAM)를 사용하면 괜찮을 것입니다.

        나보다 더 정통한 기술 전문가들은 t3.large 인스턴스를 Ethereum 2.0의 합리적인 옵션으로 권장했습니다. t3.large에는 m5.large와 동일한 2 개의 vCPU와 8GB 메모리가 있지만 t3 제품군은 일관된 CPU로드를 위해 구축 된 m5 제품군이 아닌보다 “버스트 가능한”네트워크 활동 (CPU의 스파이크)을 위해 구축되었습니다..

        가격

        스토리지로 이동하기 전에 마지막으로 언급 할 사항은 가격입니다. AWS는 Digital Ocean과 같은 다른 옵션에 비해 비쌉니다. 사용량에 따라 CPU (인스턴스 패밀리) 및 스토리지 (하드 드라이브) 비용을 별도로 지불합니다. CPU는 시간 단위로 지불됩니다. 검증 인은 24 시간 온라인 상태 여야하므로 아래 가격표 (2020 년 12 월부터)를 사용하여 대략적인 계산을 할 수 있습니다. 

        주문형 가격입니다. AWS는 예약 인스턴스 요금, 가상 인스턴스를 1 년에서 3 년으로 약속하면 위의 가격표에서 최대 50-60 %의 비용을 절감 할 수 있습니다. (이 팁에 대해 Jason Chroman에게 감사드립니다!)

        EC2 홈페이지에서 아래와 같이 왼쪽 메뉴의 “예약 된 인스턴스”를 클릭합니다.

        “Purchase Reserved Instance”를 클릭합니다.

        팝업 메뉴에서 인스턴스 유형 세부 정보와 가격을 확인하려는 시간을 입력합니다 (m5.xlarge 및 36 개월 기간 선택).

        “검색”을 클릭하고 가격 옵션을 확인하십시오.

        50 %가 넘는 상당한 가격 할인이 있다고 생각하지만 3 년 동안 고정되어 있습니다. 예약 인스턴스를 구매하면 AWS는이를 기존 가상 박스에 적용하거나 시작된 후 적용합니다. 여기에는 저장 공간 (하드 드라이브)이 포함되지 않습니다.. 

        참고 : AWS가 1 ~ 3 개의 Ethereum 2.0 유효성 검사기 노드를 스테이 킹하는 개인에게 가장 적합한 옵션이라고 아직 확신하지 못하기 때문에 아직이 작업을 수행하지 않습니다.. 약정하기 전에 어떻게 진행되는지 확인하기 위해 주문형 가격으로 인스턴스를 실행하고 있습니다.. 

        저장

        인스턴스 시작 프로세스로 돌아가서 “스토리지 추가”탭으로 이동합니다.

        제가 상담 한 뛰어난 기술 담당자는 100GB 범용 SSD의 저장 용량을 권장했습니다. 스토리지는 일반적으로 Eth2 클라이언트의 병목 현상이 아닙니다.. 그러나 이것은 없이 완전한 Eth1 클라이언트 실행. Eth1 스토리지의 경우 보수적 인 추정치는 약 1TB입니다. Infura를 사용하지 않는 경우이를 고려하십시오..

        위 이미지의 IOPS 열에있는 단위는 모르지만 CPU와 통신하는 하드 드라이브의 입력-출력입니다. 이것은 전체 Eth1 노드 동기화에 대한 고전적인 병목 현상입니다. 이 컴퓨터에서 전체 Eth1 클라이언트를 동기화하려고하는데 문제가있는 경우이 곳을 살펴볼 수 있습니다..

        항구

        “태그 추가”를 건너 뛰고 “보안 그룹 구성”으로 이동합니다. 이들은 인스턴스와의 다양한 수신 및 발신 통신을 위해 생성 된 다양한 개구부입니다..

        AWS는 인스턴스와 상호 작용하는 주요 방법이므로 기존 SSH 포트를 자동으로 엽니 다.. 코인 캐슈Somer Esat의 훌륭한 가이드는 모두 SSH에 대한 암호 액세스를 비활성화하는 것을 권장하지만 AWS의 기본 옵션이 아닌 인스턴스를 시작할 때 알 수 있습니다. 그러나 SSH 포트를 1024-65535 사이의 숫자로 무작위로 지정하는 것이 좋습니다. 이는 악의적 인 행위자가 표준 SSH 포트를 네트워크에서 스캔하는 것을 방지하기위한 것입니다. 일반적으로 SSH 포트를 보호하는 방법보기 여기 특히 AWS를 위해 여기.

        Teku 클라이언트를 수용하기 위해 두 가지 보안 규칙을 추가해야하며 이는 P2P 통신과 관련이 있습니다. 블록 체인 네트워크는 노드가 서로 직접 통신한다는 점에서 분산되어 있습니다. 중앙 노드를 참조하는 대신 개별 노드는 여러 노드와 “가시 핑”하여 네트워크 상태에 대한 이해를 개발하고 유지합니다. 즉, 한 클라이언트가 다른 클라이언트와 핸드 셰이크 할 때 네트워크에 대한 정보를 교환합니다. 다른 노드로 충분한 시간을 수행하면 정보가 네트워크 전체에 전파됩니다. 현재 내 Eth2 Validator 노드에는 채팅중인 74 개의 피어가 있습니다..

        Teku는 9000 포트의 다른 노드와 통신하므로 UDP 및 TCP에 대해 열어 보겠습니다., 두 가지 다른 종류의 통신 프로토콜. 

        나중에 다음과 같이 보일 것입니다.

        SSH 키 및 인스턴스 시작

        마지막으로 선택한 항목에 대한 개요 인 “검토 및 실행”으로 이동합니다. 승인되면 SSH 키에 대한 팝업 메뉴가 표시됩니다. 민감한 정보가 포함되어 있으므로 표시하지 않습니다. 즉, SSH (로컬 명령 줄)를 통해 가상 인스턴스를 인증하고 로그인하는 데 사용되는 키 쌍입니다. 쌍이 아직없는 경우 AWS에서 자동으로 생성합니다.. 이것을 다운로드하고 이더 리움 개인 키처럼 취급해야합니다! 인스턴스에 연결하는 유일한 방법이며 AWS는이를 저장하지 않습니다..

        모든 것이 엉망이되면 다음 창이 나타납니다.

        괜찮아! 이제 인스턴스에 액세스하고 보안을 설정 한 다음 Teku를 설치하고 실행하겠습니다.!

        인스턴스 액세스

        AWS 인스턴스에 액세스하는 주요 방법은 SSH를 사용하는 것입니다., “보안되지 않은 네트워크를 통해 네트워크 서비스를 안전하게 운영하기위한 암호화 프로토콜” 앞서 언급했듯이 AWS는 기본적으로 인스턴스 액세스를위한 암호 인증을 비활성화합니다. 인스턴스 시작 전에 생성 된 키 페어 만 사용할 수 있습니다. 키 쌍은 a.pem 파일로 끝나야합니다.. 

        AWS는 SSH 명령을 얻는 깨끗한 방법을 제공합니다. 기본 EC2 페이지에서 실행중인 인스턴스를 클릭하면 오른쪽 상단에 “연결”이라는 버튼이 있습니다.

        다음 페이지에는 인스턴스에 특정한 SSH 명령이 있습니다. 다음과 같이 구성됩니다.

        ssh -i "PATH_TO_AWS_KEYPAIR.pem" [이메일 보호]_IDENTIFIER.compute-ZONE.amazonaws.com

        이 명령을 터미널에 입력하면 SSH 세션이 시작됩니다. 처음으로 로컬 시스템은 AWS에서 제공하는 ECDSA 지문을 신뢰할 것인지 묻습니다. 이것은 man-in-the-middle 공격 그리고 우려되는 경우 사용자는 다음과 같은 인스턴스의 지문을 얻을 수 있습니다. 이 단계.

        현재 SSH 세션과 다른 터미널에서 Teku를 실행하는 데 필요한 유효성 검사기 키 파일을 전송합니다. 이전 블로그 게시물에서 32 개의 ETH를 스테이 킹하고 Ethereum 2.0에 대한 유효성 검사기 키를 얻는 과정을 살펴 보았습니다. 결국 다음과 같은 파일 구조가 남았습니다.

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

        validator_key_info 파일을 가상 인스턴스로 전송해야합니다. SCP (Secure Copy Protocol)를 사용하면이 작업을 안전하게 수행 할 수 있습니다. 위의 디렉토리 경로와 이전 SSH 명령을 사용하여 아래의 일반 scp 명령을 조정하십시오.

        scp -r -i "PATH_TO_AWS_KEYPAIR.pem" / PATH_TO_KEYS / eth2deposit-cli / validator_key_info / [이메일 보호]_IDENTIFIER.compute-ZONE.amazonaws.com:~

        (전체 명령 끝에있는 “: ~”에 유의하십시오.)

        파일 전송이 발생하는 것을 볼 수 있습니다. SSH 세션으로 돌아가서 ls를 입력하면 전송 된 디렉토리가 표시됩니다..

        Teku 설치

        이제 필요한 유효성 검사기 파일이 준비되었으므로 Teku를 설치할 것입니다. 먼저 기존 프로그램을 업데이트하고 필요한 Java 시스템을 설치해야합니다.

        Java 설치

        sudo apt 업데이트 && sudo apt install default-jre && sudo apt install default-jdk

        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 └─ KEY ├── ─ validator_key_info / ─ validator_key_info / ─ -M_123456_789_ABCD.json ├── KEYSTORE-M_123456_789_ABCD.txt └── DEPOSIT_DATA_YOUR_TIMESTAMP_HERE.json

        루트가 아닌 사용자 만들기

        이 단계는 Somer Esat의 우수한 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의 우수한 Ubuntu / Teku 튜토리얼

        이 단계는 백그라운드에서 Teku를 실행할 서비스를 만듭니다. 또한 어떤 이유로 인해 서비스가 중지되면 컴퓨터가 자동으로 서비스를 다시 시작할 수 있습니다. 이는 유효성 검사기가 연중 무휴로 실행되도록하는 데 필요한 단계입니다..

        nano 텍스트 편집기를 사용하여 서비스 파일을 만듭니다.

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

        이 파일 (비어 있어야 함)에는 서비스를 시작할 때 systemd가 실행할 일련의 명령을 입력합니다. 아래 코드는이 여정 동안 수집 한 다음 항목을 구독해야합니다.

        • Infura Eth1 HTTP 끝점
        • 두 개의 유효한 키 관련 파일이있는 validator_key_info 디렉토리 경로
        • 사용자 지정 데이터 경로 (lib / var / teku)

        아래의 굵은 코드에 해당 값을 입력 한 다음 모두 나노 텍스트 편집기에 복사합니다.

        [단위] 설명 = Teku Beacon Node Wants = network-online.target After = network-online.target [서비스] 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_789_ABCD.txt –rest-api-enabled = true –rest-api-docs-enabled = true –metrics-enabled –validators-keystore-locking-enabled = false –데이터베이스 경로 = / var / lib / teku [설치] WantedBy = multi-user.target

        command-X를 입력 한 다음 “Y”를 입력하여 변경 사항을 저장합니다.

        업데이트하려면 “systemctl”을 다시 시작해야합니다.

        sudo systemctl 데몬 다시로드

        서비스 시작 :

        sudo systemctl start teku

        제대로 시작되는지 확인합니다.

        sudo systemctl 상태 teku

        오류가 표시되면 다음을 실행하여 자세한 내용을 확인하세요.

        sudo journalctl -f -u teku.service

        다음을 실행하여 Teku 서비스를 중지 할 수 있습니다.

        sudo systemctl stop teku

        Teku 문제 해결 페이지에서 일반적인 오류 또는 Teku 불화를 확인하십시오, 팀에서 모니터링하는.

        문제가 해결되었다고 생각되면 다음을 실행하여 종료 된 경우 서비스를 다시 시작합니다.

        sudo systemctl 활성화 teku

        거기 있습니다! 지금 당장 일이 ​​진행되고있을 것입니다. Teku 서비스를 검사 할 때 동기화 이벤트를 기록하는 일련의 로그가 표시됩니다. 이것은 비콘 체인을 동기화하는 유효성 검사기입니다. 헤드에 도달하면 해당 로그가 슬롯 이벤트를 읽도록 변경되며 증명 성능 및 블록 제안도 볼 수 있습니다..

        시작하다

        출처 : Beaconcha.in

        12 월 1 일 12pm UTC에 Beacon Chain의 첫 번째 블록이 검증되었습니다. 첫 번째 블록은 유효성 검사기 19026, 수수께끼 같은 낙서와 함께“F 씨가 여기 계셨습니다.” 12 초 후 다음 블록이 나타났습니다. 추크, 스위스. Eth2 비콘 체인은 12 초마다 블록 단위로 꾸준히 성장했습니다. 그런 다음 다음 장애물이 왔습니다. 첫 번째 Epoch를 완료하기에 충분한 검증 인이 온라인 상태일까요? 예! 82.27 %의 검증 자들이 비콘 체인의 1 층인 Epoch 0의 유효성을 증명했습니다. 여기에서 비콘 체인 출시 및 향후 계획에 대해 자세히 알아볼 수 있습니다.. 

        출처 : Beaconcha.in

        우리는 이제 Epoch 760에 있습니다. 이는 비콘 체인이 거의 일주일 동안 원활하게 운영되고 있음을 의미합니다.. 

        다음은이 게시물에 설명 된 설정을 사용하여 생성 순간에 대한 저의 관점에서 찍은 사진입니다.

        다음 기사에서는 상황을 요약 해 보겠습니다. 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에게 지원 및 기술 지원을 제공합니다..

        이더 리움 2.0 뉴스 레터 최신 이더 리움 뉴스, 엔터프라이즈 솔루션, 개발자 리소스 등에 대한 뉴스 레터를 구독하십시오.

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