작성자: Marco González
편집자: Randall Roland
옮긴이: Sangyong Jeong
"Node Operator Roundtable"은 매주 안텔로프(Antelope) 코어 개발자와 커뮤니티 구성원들이 모여서 운영됩니다. "Node Operator Roundtable"의 주요 목표는 다음과 같습니다.
"안텔로프(Antelope) 프로토콜을 특히 노드 운영자를 위해 개선하는 것입니다..."
회의는 매주 수요일 14시 UTC에 진행되며 1시간 동안 진행됩니다.
2월 1일 회의 : Leap v3.2+에서 노드 운영자를 위한 구성 매개변수(config parameters)에 관해
2월 1일의 라운드테이블에서는 현재(Leap v3.2) 및 미래의 구성 매개변수에 대해 탐구했습니다. 토론 중반에는 노드 구성이 더욱 더 신경써야 할 주제임이 분명해졌습니다.
UPDATE: Leap, DUNE, 그리고 Ubuntu
최근 DUNE v1.1을 출시하면서, Leap은 개발 및 노드 운영의 진입 장벽을 완화하고자 하는 방향으로 나아가고 있습니다. 3월 테스트 전, Ubuntu 18.04에 대한 지원이 중단될 것입니다. Ubuntu를 사용하려는 개발자는 이점에 유의 해주세요. Ubuntu 버전 20.04 및 22.04는 공식적으로 지원됩니다.
이번 3월 테스트에는 합의 업그레이드가 포함되지 않을 것입니다. 2월 8일 라운드테이블에서는 9월 즈음에 합의 업그레이드가 진행될 수 있는 시점으로 언급했습니다.
회의 노트
특수 목적 노드를 구성하는 것이 굉장히 복잡한 문제임이 입증되고 있습니다. 이에 관해 새롭게 정리된 문서가 필요합니다. Leap 3.2 문서가 버전 업그레이드 전 구성 설정을 해결하기 위해 개선이 필요하다는 점이 회의에서 강조되었습니다.
HTTP 응답 시간 문제가 회의의 주요 내용 중 하나였습니다. 응답 시간은 최대 직렬화 시간(max serialization time)과 적어도 동일해야 한다는 것에 대해 합의가 이루어졌습니다. 인바운드와 아웃바운드 균형을 유지하기 위해 응답 시간을 더 높게 설정할 수도 있습니다. 예를 들어, 큰 블록에서 타임아웃하는 HTTP 요청이 실패할 수 있습니다. 이러한 문제를 설명하기 위해 Atomic Hub가 사용되었습니다.
또한, 과도한 호출 데이터와 전반적인 효율성도 고려해야 합니다. 토의 초반에는 "boost 라이브러리" 및 전략적 변화에 대한 기대가 언급되었습니다.
해당 녹화본을 EOS 재단 YouTube 채널에서 확인해보세요.
전망
이번 회의에서는 잠재적인 노드 구성 및 응용 프로그램에 대한 노트가 많은 시간을 차지했습니다. 다음 주의 토론 주제는 "특수 목적 노드"입니다.
특정 요구 사항에 대해 노드를 최적으로 구성하는 방법은 다음 주의 토론을 넘어서 확장될 것으로 예상됩니다. 개선이 필요한 주요 분야는 다음과 같습니다.
압력 완화(alleviating pressure)
읽기 전용(read-only)
효율성(efficiency)
블록 전파(block propagation)
압력 완화와 효율성과 같은 항목은 종종 서로 관련되어 있음을 유의해야 합니다. 특수 목적 노드와 그 분류는 추상적인 개념을 다루므로, 이번 토론에서는 이를 보다 명확하기 하기 위한 방법의 추가도 주요 목표입니다.
2월 8일: 특수 목적 노드
2월 8일의 라운드테이블에서는 노드가 구성되고 사용되는 다양한 방법을 분류하는 과정이 시작되었습니다. Antelope 노드 분류 문서(Antelope node taxonomy document)가 Leap v4.0에 앞서 개발 중이며 (목표 일정은 3월 말입니다), 가능한 한 빠른 시일 내에 합의 Leap 업그레이드가 예상됩니다.
UPDATE:
3월과 9월 목표 일정 외에도, Leap 4.0을 위한 코드 동결에 대한 발표가 예상됩니다.
특수 목적에 관한 토론 정보
특수 목적 노드는 모든 잠재적 사용 사례를 개념화한 모델입니다. 노드 사용 및 구성을 조직하는 것은 EOS 개발자들 사이에서 오랜 시간 동안 공감되어 왔던 주제이며, 4.0 버전에서는 노드 운영자들이 일상적인 관리를 간소화하는 데 큰 도약을 경험할 것입니다.
Brian Hazzard는 노드 아이디어 회의 과정을 "레고 블록"에 비유하기도 했습니다. Antelope 노드의 특성과 이에 따른 역할은 종종 추상적입니다. 커뮤니티의 피드백은 환영됩니다. 현재 노드 특성 또는 느슨한 분류의 목록은 guiding document: 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에 게시되지 않음) 의도적으로 광고해서는 안된다는 점을 유의하세요.
Stephen Diesel의 코멘트는 릴레이에 준비된 블록이 일관적으로 제공될 수 있는 피어 그룹을 유지해야 함을 보여줍니다. 준비 상태를 유지하는 것은 동기화된 트랜잭션 뿐만 아니라 새로운 블록을 수락할 준비도 갖추는 것을 의미합니다. 준비 상태를 유지하지 않는 것은 빈 블록의 원인 중 하나로 지적되었습니다.
트랜잭션 릴레이 노드
블록 릴레이 노드와 마찬가지로, 트랜잭션 릴레이 노드도 헤더 유효성 검사 후 블록 전달을 위해 작동할 수 있습니다. 트랜잭션 릴레이 노드를 구분짓는 것은 다음과 같은 능력입니다:
대기 중인 트랜잭션(pending transactions)
선호하는 피어로부터의 트랜잭션(transactions from preferred peers)
P2P 또는 API를 통해 공개된 트랜잭션 수락 가능성(public transactions via P2P or API)
추가 노트:
Kevin Heifner는 헤더 유효성 검증 후 블록 전파를 개선하기 위한 솔루션에 대한 링크를 공유했습니다. EOSUSA 마이클은 자신의 노드 설정을 보여주는 다이어그램을 공유했습니다(2월 8일 라운드테이블 참조).
앞으로는 최적의 사례를 탐구하고 상세히 설명할 예정입니다. 노드 유형은 세 가지 기본 구성을 가지고 있는 것으로 보입니다:
nodeos
머신 코드(machine code)
네트워킹
전망
드래프트 문서의 다음 5개 노드 분류는 다음과 같습니다.
Push API Node
Node API Node
Chain API Node
State API Node
Developer Node
특수 목적 노드에 대한 토론 시리즈는 다음 주에 위의 (API) 분류, 모범 사례 및 관련 문서에 초점을 맞추어 계속될 예정입니다.
출처 및 참고문헌