작성자: Marco González

편집자: Randall Roland

옮긴이: Sangyong Jeong

노드 운영자, 안텔로프(Antelope) 코어 개발자, 그리고 커뮤니티 구성원들은 매주 흥미로운 주제에 관해 논의합니다. 노드 운영자 라운드 테이블의 주요 목표는 다음과 같습니다:

"노드 운영자들을 위해 Antelope 프로토콜을 개선하는 것"

회의는 매주 수요일 오후 14시부터 15시까지 진행됩니다.

3월의 첫 두 라운드테이블 회의에서는 특수 노드에 관한 논의가 이어졌으며, 특히 가장 실용성 있는 방안에 관해 논의했습니다. 3월 1일 라운드테이블에서는 BP 노드의 목표 및 이와 관련된 가장 실용적 방안을 탐구했으며, 3월 8일에는 블록 전용 릴레이 노드에 대한 논의를 마쳤습니다. "코드 동결"에 관한 정보는 3월 8일 라운드테이블 전후 발표 예정입니다. Leap 4.0.0 테스트넷 릴리스에 관하여, 개발팀은 3월 말/4월 초를 발표를 목표로 진행 중입니다.

"다양한 노드 역할에 대한 초안 분류 체계(draft taxonomy of the roles that different antelope nodes play)"는 포괄적인 노트를 포함하고 있습니다. 특수 노드 논의의 시작을 탐색하려면 GitHub의 'Post Upgrade meetings' 섹션을 방문해 확인하세요.

"ENF’s YouTube"에서 3월 1일 라운드테이블 논의를 시청하시고, EOS Nation (Leap) GitHub의 노트를 읽어보십시오.

3월 1일 라운드테이블은 특수 용도 노드에 관한 지속적인 논의 중 4번째입니다. 이에 관한 문제 중 하나는 생태계 전반에 걸쳐 더 효율적인 리소스 모델입니다. 이에는 삼진아웃 제도와 주관적 청구(subjective billing) 요구 사항이 포함됩니다.

이 그룹은 History provider에 대한 표기를 가져왔습니다. 초안 문서에서 역사를 특별히 언급하는 주요 노드 유형(Primary Node types)에는 다음이 포함됩니다:

히스토리 관련 Layer-2 솔루션:

"상태 히스토리(state history)"에 관한 문제 중 일부는 다음과 같습니다:

히스토리와 관련된 후속 제안:

노드 유형 리스트는 리소스 제공 노드(Resource Provider Node)로 끝나며, 이는 세 번째 Layer-2 솔루션으로 간주됩니다. 이 노드의 목적은 사용자 경험 향상입니다. 현재 리소스 제공 노드는 node.js에서 실행되지만, API 플러그인처럼 탈중앙화될 수도 있습니다. 초안 분류 체계 문서에서 리소스 제공 노드는 다음과 같이 정의됩니다:

이 회의는 최적의 구성을 위한 노력과 요구 사항 및 최상의 관행에 대한 논의를 계속했습니다. 최상의 관행의 주요 목표 중 하나는 Antelope 네트워크(예: WAX, Telos 등) 전반에서 최소 기준을 확인하는 것입니다.

네트워크별로 다양한 요구 사항이 있기 때문에 최상의 관행에 대한 논의가 있을 것으로 예상됩니다. 예를 들어, 다음은 블록체인 네트워크 활용에 따라 다양합니다:

가장 실용적인 장치 요구사항이 해당 논의에서 중점적으로 다루어졌습니다. 노드 유형을 변경할 때 운영자는 전반적인 nodeos 구성을 확인해야 합니다. 예를 들어, 시작 및 중지와 같은 방식으로 실행할 경우, CPU를 AtticLabs의 권장 사항에 맞게 재조정해야 합니다. AtticLabs 링크 및 ECC RAM, x86 프로세서 등의 기타 장치 요구 사항은 초안 분류 체계 문서를 참조하세요.

라운드테이블 회의 마무리 즈음, 보안 관련 최선의 설정 및 하드웨어 키 재사용에 관한 추가 노트가 있었습니다.

체인 API 노드(Chain API Node)는 블록 프로듀서 노드를 위한 nodeos 구성의 모범 운용 방안에 대한 최종 합의를 도출했습니다. 권장 사항은 다음과 같습니다:

Chain API Node의 토론은 사용 가능해야 할 것에 대한 결론을 내렸습니다 (예: Getinfo로 단순화되지만 Prometheus가 다른 해결책을 제공 할 수 있음).

일부 노드 유형은 가변적인 구성이 필요할 수 있으므로 이를 염두에 두어야 합니다. 회의는 추가 후속 조치 항목으로 마감되었으며 (임시 분류 체계 문서의 다음 단계 섹션에 기재되어 있음), 이에 대한 추가적인 조치가 이루어질 예정입니다.

3월 8일 라운드테이블 논의 내용은 ENF의 유튜브에서 시청하실 수 있습니다. 또한 EOS Nation (Leap)의 GitHub에서 해당 논의에 대한 노트를 읽으실 수 있습니다.

Antelope 팀은 월말/4월 초 출시 예비 버전을 준비 중이라고 보고하고 있습니다. Antelope Leap 4.0.0의 미래 지향적인 개발은 일단 완료되었습니다. '코드 동결'에 대한 발표가 곧 예정되어 있습니다. 4.0.0 출시 예비 버전은 곧 발표될 것으로 예상됩니다.

처음에는 블록 프로듀서 노드를 위한 nodeos 구성 모범 사례에 대한 논의가 다시 시작되었습니다. 대개 피어링(Peering)은 내부적으로 이루어집니다. 이 경우 WireGuard 키로 내부 노드 네트워크를 보호하는 것이 효과적이며 WireGuard는 하나의 옵션입니다. 이러한 키는 의도하지 않은 커넥션을 방지합니다.

다음 단계 항목 아래에는 특별한 사용 사례 시나리오(예: 재동기화)도 포함되어 있습니다. 효율성을 높이는 것도 고려해 보는 것이 좋습니다.

라운드테이블의 나머지 부분은 블록 전용 릴레이 노드(Block-only Relay Nodes) 및 해당 구성 최적화에 대한 내용이었습니다. 그룹은 커넥션 수에 대해 상세히 논의했습니다. 이전 미팅에서는 10 ~ 15개의 커넥션이 적당하다고 판단되었습니다.

Leap 3.2 관련 회의에서는 Block-only Relay Node 커넥션 수를 25-50으로 최대화해도 안전하다는 의견이 제시되었습니다. 몇 가지 노트가 추가되었습니다.

블록전용 릴레이 노드(Block-only Relay Node)의 장치 요구사항 중 언급된 첫 번째는 단일 실패 지점 유지를 피하기 위해 하나 이상이 필요하다는 것입니다.

토론의 대부분은 연결성과 속도에 초점을 맞추고 있습니다. 신뢰성 있는 인터넷 연결과 빠른 디스크, 특히 쓰기에 집중된 디스크가 강조되었습니다. 전체 블록 로그 대 부분 블록 로그에 대한 다른 최상의 사례는 초안 분류 체계 문서에서 확인할 수 있습니다. Leap 4.0에서는 자동 노드 연결 기능이 예상됩니다.

여기서 일반적 오해와의 중요한 다른 점이 있습니다. Antelope 체인에서 스냅샷은 현재 상태만(just the current state)을 의미합니다. 이는 이더리움의 스냅샷 정의와는 다릅니다. 따라서 Antelope 체인에서는 피어 네트워크가 전체 블록 로그의 '충분한' 부분(‘enough’ of a full block-log)만을 필요로 합니다. 내부 릴레이에 대해서는 전체 기록이 필요하지 않습니다.

분류 체계 초안 토론에서는 모범 사례 외의 변수 조정(adjusting variables)이 미치는 영향이 언급되었습니다. 예를 들어, 순수 블록 전용 릴레이 노드는 블록 이외의 것을 수용하지 않습니다. 또한, Leap 4.0에서는 블록 전용 릴레이 노드가 필요하지 않을 수도 있습니다.

다음 주 라운드테이블에서는 API 노드에 특화된 nodeos 구성에 대한 최상의 모범 사례에 대한 토론이 계속될 것으로 예상됩니다.