"노드 운영자 라운드 테이블"은 매주 안텔로프(Antelope) 코어 개발자와 커뮤니티 구성원들이 모여서 운영됩니다. "노드 운영자 라운드 테이블"의 주요 목표는 다음과 같습니다.
"안텔로프(Antelope) 프로토콜을 특히 노드 운영자를 위해 개선하는 것입니다..."
노드 운영자 라운드 테이블
노드 운영자 라운드 테이블 회의는 매주 수요일 14시 UTC에 진행되며 1시간 동안 진행됩니다.
2월 1일 회의 : 리프(Leap) v3.2+에서 노드 운영자를 위한 구성 매개변수(config parameters)에 관해
2월 1일의 라운드테이블 에서는 현재(Leap v3.2) 및 미래의 구성 매개변수에 대해 탐구했습니다. 토론 중반에는 노드 구성이 더욱더 신경써야 할 주제임이 분명해졌습니다.
업데이트: 리프, D.U.N.E, 그리고 우분투(Ubuntu)
최근 DUNE v1.1을 출시하면서, 리프는 개발 및 노드 운영의 진입 장벽을 완화하고자 하는 방향으로 나아가고 있습니다. 3월 테스트 전, 우분투 18.04에 대한 지원이 중단될 것입니다. 우분투를 사용하려는 개발자는 이점에 유의해 주세요. 우분투 버전 20.04 및 22.04는 공식적으로 지원됩니다.
이번 3월 테스트에는 합의 업그레이드가 포함되지 않을 것입니다. 2월 8일 라운드 테이블에서는 9월 즈음에 합의 업그레이드가 진행될 수 있는 시점으로 언급했습니다.
회의 노트
특수 목적 노드를 구성하는 것이 굉장히 복잡한 문제임이 입증되고 있습니다. 이에 관해 새롭게 정리된 문서가 필요합니다. 리프 3.2 문서가 버전 업그레이드 전 구성 설정을 해결하기 위해 개선이 필요하다는 점이 회의에서 강조되었습니다.
HTTP 응답 시간문제가 회의의 주요 내용 중 하나였습니다. 응답 시간은 최대 직렬화 시간(max serialization time)과 적어도 동일해야 한다는 것에 대해 합의가 이루어졌습니다. 인바운드와 아웃바운드 균형을 유지하기 위해 응답 시간을 더 높게 설정할 수도 있습니다. 예를 들어, 큰 블록에서 타임아웃하는 HTTP 요청이 실패할 수 있습니다. 이러한 문제를 설명하기 위해 아토믹 허브(Atomic Hub)가 사용되었습니다.
또한, 과도한 호출 데이터와 전반적인 효율성도 고려해야 합니다. 토의 초반에는 "부스트(boost) 라이브러리" 및 전략적 변화에 대한 기대가 언급되었습니다.
해당 녹화본을 ENF(이오스 네트워크 재단) 유튜브 채널에서 확인해보세요.
전망
이번 회의에서는 잠재적인 노드 구성 및 응용 프로그램에 대한 노트가 많은 시간을 차지했습니다. 다음 주의 토론 주제는 "특수 목적 노드"입니다.
특정 요구 사항에 대해 노드를 최적으로 구성하는 방법은 다음 주의 토론을 넘어서 확장될 것으로 예상됩니다. 개선이 필요한 주요 분야는 다음과 같습니다.
- 압력 완화(alleviating pressure)
- 읽기 전용(read-only)
- 효율성(efficiency)
- 블록 전파(block propagation)
압력 완화와 효율성과 같은 항목은 종종 서로 관련되어 있음을 유의해야 합니다. 특수 목적 노드와 그 분류는 추상적인 개념을 다루므로, 이번 토론에서는 이를 보다 명확하기 하기 위한 방법의 추가도 주요 목표입니다.
2월 8일: 특수 목적 노드
2월 8일의 라운드 테이블에서는 노드가 구성되고 사용되는 다양한 방법을 분류하는 과정이 시작되었습니다. 엔텔로프(Antelope) 노드 분류 문서(Antelope node taxonomy document)가 리프 v4.0에 앞서 개발 중이며 (목표 일정은 3월 말입니다), 가능한 한 빠른 시일 내에 합의 리프 업그레이드가 예상됩니다.
업데이트:
3월과 9월 목표 일정 외에도, 리프 4.0을 위한 코드 동결에 대한 발표가 예상됩니다.
특수 목적에 관한 토론 정보
특수 목적 노드는 모든 잠재적 사용 사례를 개념화한 모델입니다. 노드 사용 및 구성을 조직하는 것은 이오스 개발자들 사이에서 오랜 시간 동안 공감되어 왔던 주제이며, 4.0 버전에서는 노드 운영자들이 일상적인 관리를 간소화하는 데 큰 도약을 경험할 것입니다.
브라이언 하자드(Brian Hazzard)는 노드 아이디어 회의 과정을 "레고 블록"에 비유하기도 했습니다. 엔텔로프 노드의 특성과 이에 따른 역할은 종종 추상적입니다. 커뮤니티의 피드백은 환영됩니다. 현재 노드 특성 또는 느슨한 분류의 목록은 가이드 문서: draft taxonomy of the roles that different antelope nodes play를 참조하세요.
예비 분류
이번 라운드 테이블에서 검토된 노드 분류는 다음과 같습니다:
- 블록 프로듀서 노드: BP 합의에 따라 블록을 체인에 추가하는 역할을 합니다.(subject to BP consensus to organize and add blocks to the chain)
- 블록 릴레이 노드: 피어 노드로부터 블록을 받아들이고, 헤더를 확인한 후 다른 피어 노드에 릴레이합니다.(receive peer blocks, validate headers, and then relay to the rest of the peer group)
- 트랜잭션 릴레이 노드: 피어 노드로부터 블록을 받아들이고, 트랜잭션을 확인한 후 트랜잭션을 다른 피어 노드에 릴레이 합니다.(receive peer blocks, validate signatures, and then relay to the rest of the peer group )
논의된 노드 유형 개요
다음은 이 회의에서 논의된 노드 유형 개요입니다. 자세한 내용은 GitHub (해당 주의 이슈 참조)와 초안 문서(taxonomy draft document)에서 확인할 수 있습니다.
블록 프로듀서 노드
합의가 필요한 노드의 특성은 다음과 같습니다:
- 실패 회피에 초점을 두고 대기 중인 트랜잭션을 보장합니다.(ensure pending transactions with a primary focus on avoiding failure)
- 대기 중인 유효 트랜잭션을 효과적으로 처리합니다.(effectively receive valid pending transactions)
- 남용을 방지합니다.(isolate from abuse (e.g. TCP, UDP, and internet))
- 물리적으로 키 보안을 분리합니다.(physically separate key security)
- 오픈 파이프를 유지합니다.(maintain an open pipe (for both incoming and outgoing))
- 피어 수를 낮게 유지합니다(3~5).(keep peers low (3 to 5))
가장 효율적으로 구성할 수 있는 예는 다음과 같습니다:
- 로컬 네트워크 모니터링을 위한 HTTP API 접근이 가능한 비공개 실행(privately running with HTTP API access for local network monitoring)
- 블랙리스트를 위한 Producer API(producer API for blacklists)
향후 고려 사항은 분류체계 초안 문서를 참조하십시오.
블록 릴레이 노드
이번 회의에서 가장 기본적으로 고려된 블록 릴레이 노드입니다. 블록 릴레이 노드의 정의는 피어들과의 연결을 유지하고 블록 헤더 유효성을 검사하는 것을 말합니다. 스테픈 디젤(Stephen Diesel)은 다음과 같이 언급했습니다.
"좋은 블록이 들어가면, 좋은 블록이 나온다."
스테픈 디젤
릴레이 노드의 장점은 BP 노드보다 더 많은 피어 (10-15)와 함께 작동할 수 있다는 것입니다. 또한 블록 릴레이 노드는 공개될 수는 있지만 (예: bp.json에 게시되지 않음) 의도적으로 광고해서는 안 된다는 점을 유의하세요.
스테픈 디젤의 코멘트는 릴레이에 준비된 블록이 일관적으로 제공될 수 있는 피어 그룹을 유지해야 함을 보여줍니다. 준비 상태를 유지하는 것은 동기화된 트랜잭션뿐만 아니라 새로운 블록을 수락할 준비도 갖추는 것을 의미합니다. 준비 상태를 유지하지 않는 것은 빈 블록의 원인 중 하나로 지적되었습니다.
트랜잭션 릴레이 노드
블록 릴레이 노드와 마찬가지로, 트랜잭션 릴레이 노드도 헤더 유효성 검사 후 블록 전달을 위해 작동할 수 있습니다. 트랜잭션 릴레이 노드를 구분 짓는 것은 다음과 같은 능력입니다:
- 대기 중인 트랜잭션(pending transactions)
- 선호하는 피어로부터의 트랜잭션(transactions from preferred peers)
- P2P 또는 API를 통해 공개된 트랜잭션 수락 가능성(public transactions via P2P or API)
추가 노트:
케빈 헤프너(Kevin Heifner)는 헤더 유효성 검증 후 블록 전파를 개선하기 위한 솔루션에 대한 링크를 공유했습니다. 이오스USA(EOSUSA) 마이클(Michael)은 자신의 노드 설정을 보여주는 다이어그램을 공유했습니다(2월 8일 라운드테이블 참조).
앞으로는 최적의 사례를 탐구하고 상세히 설명할 예정입니다. 노드 유형은 세 가지 기본 구성을 가지고 있는 것으로 보입니다:
- nodeos
- 머신 코드(machine code)
- 네트워킹
전망
드래프트 문서의 다음 5개 노드 분류는 다음과 같습니다.
- Push API Node
- Node API Node
- Chain API Node
- State API Node
- Developer Node
특수 목적 노드에 대한 토론 시리즈는 다음 주에 위의 (API) 분류, 모범 사례 및 관련 문서에 초점을 맞추어 계속될 예정입니다.
출처 및 참고문헌
- EOS Support Learning Center
- EOS Support Media
작성자: Marco González
편집자: Randall Roland
옮긴이: Sangyong Jeong, Terry Jin
이오스 서포트가 2023년 2월 28일 발간한 기사입니다.
이오스 서포트는 이오스 네트워크의 신뢰할 수 있는 안내자이자 커뮤니티 기반 글로벌 고객 지원 서비스 센터입니다.
이오스 서포트 라이브는 모든 유형의 이오스 사용자를 돕기 위한 24시간 연중무휴 1:1 고객 지원 서비스를 9개 언어로 제공하고 있습니다.
이오스 서포트 플러스: 이오스 및 엔텔로프 소프트웨어에 관한 교육자료 및 가이드, 스캠 주의보, 이오스 네트워크 운영 기술 지원, 초보자 학습센터, 경품 이벤트 등 더욱 다양한 서비스를 제공합니다.
이는 지역 커뮤니티를 활성화하고, 이오스 생태계를 더욱 확장합니다. 저희의 공식 웹사이트 및 소셜 계정을 방문하시고 이오스에 관한 최신 소식과 최고의 고객 서비스를 만나보세요!
[서포트 고객 센터 이용방법]
1. EOSsupport.io 접속
2. 오른쪽 하단 1:1 상담문의 채팅 클릭
3. 이오스 관련 문의사항 질문하기
