작성자: Marco González
편집자: Randall Roland
옮긴이: Sangyong Jeong
노드 운영자(Node Operator), 안텔로프(Antelope) 핵심 개발자, 그리고 다양한 커뮤니티 구성원은 네트워크 발전을 위한 건설적이고 흥미로운 주제에 대해 논의합니다. 노드 운영자 회의(Node Operator Roundtable)의 목표는 다음과 같습니다:
"노드 운영자들을 위해 안텔로프 프로토콜을 개선하는 것"
회의는 매주 수요일 오후 UTC 14시부터 15시까지 진행됩니다. EOS 노드 운영의 기초를 배우고자 하는 분들을 위해, EOS 네트워크 재단(EOS Network Foundation, 이하 ENF)은 관련 튜토리얼 및 문서를 제공하고 있습니다.
다음은 이번 달 진행된 회의의 간략한 개요입니다:
6월 21일: 문제와 해결책을 기재한 P2P 개선 문서 작성
6월 28일: 블록 트리밍(Block Trimming), 립 5.0(Leap 5.0) 계획, IF(Instant Finality, 이하 IF),OC(Optimizing Compiler, 이하 OC)
깃허브(GitHub)에서 해당 회의록을 확인하시고, ENF 유튜브 채널에서 녹화 비디오를 확인하세요.
6월 21일: 문제와 해결책을 기재한 P2P 개선 문서
6월 21일에 있었던 회의에서는 P2P에 대한 토론이 계속되었습니다. 최근 몇 주 동안의 피드백에 대한 일부 답변을 담은 깃허브 문서가 토론을 이끌었습니다.
개요
이 문서는 현재 식별 가능한 문제를 명확히 정의하고 있습니다. 이와 관련해 가능한 해결책을 검토하고 그 실행 여부를 점쳐봅니다.
업데이트
회의 중에 립 4.0.3 패치가 출시되었습니다.
P2P 개선을 위한 문서 목차
이 문서는 몇 가지 카테고리로 나누어져 있습니다
문제
해결책
이슈
자원
의견
문제: 기회, 사용자 그룹, 전략
일반적으로 다양한 유형의 사용자 그룹은 저마다 다른 요구사항이 있습니다. 이 항목은 우선순위에 대한 이해를 촉진합니다.
현재 식별된 사용자 그룹은 안텔로프(Antelope) 기반 사용자로서 다음과 같습니다:
"기술적으로 능숙한 개인" 노드 운영자로서 "신뢰할 수 있고 효율적이며 단순화된 솔루션"에 관심을 가지고 있습니다.
문제를 핵심 개발과 일치시키기 위해서는 "사용자 경험 및 인프라 효율성의 개선"에 초점을 맞추어야 합니다. 성공적인 구현은 "안텔로프 프로토콜의 보다 넓은 채택과 성공"을 기대할 수 있습니다.
현재 식별된 우선순위는 다음과 같습니다:
가장 중요한 것은 "사용 가능한 블록에 대한 캐치 업 모드(catch up mode) 피어 선택의 개선"입니다.
최근 몇 주간 대역폭(Bandwidth)에 대한 토론이 이어졌습니다. "피어 대역폭 소비(peer bandwidth consumption)의 제어"를 개선하는 것이 다음 우선 순위입니다. 남용을 피하고 피어를 자동으로 교체하는 것이 중점 사항입니다.
세 번째 주요 우선 순위는 "피어 연결을 내부 또는 외부로 표시할 수 있는 능력"입니다. 이를 통해 "내부 인프라에서의 신뢰 (수준)"를 해결할 수 있을 것으로 예상됩니다.
기타 이슈에 대한 설명은 문서 및/또는 비디오에서 확인할 수 있습니다. 이에는 터미널 기반 UI(terminal-based UI), 피어 블랙리스트, 동기화(syncing) 등이 포함됩니다.
솔루션 정의와 위험 요소 식별
"P2P 개선"는 안텔로프 노드 운영에 있어 큰 변화를 가져올 것입니다. 깃허브 문서에 기재된 성공을 위한 주요 지표는 다음과 같습니다:
새로운 노드 또는 다시 시작된 노드의 동기화 시간 개선
새로운 노드 구성을 위한 단계 수 감소
P2P 네트워크를 통과하는 트랜잭션의 신뢰성 개선
P2P 네트워크를 통과하는 트랜잭션 속도 개선
위험 요소를 식별하는 과정은 실리콘 밸리 프로젝트 그룹이 작성한 "The Four Big Risks"라는 글에 따라 이끌립니다. 질문은 병렬 시간표와 관련된 P2P 피어 검색 RFP에 중점을 둡니다:
"충돌(conflict) 또는 중복(overlap)의 위험이 있을까요?"
자세한 자료와 문제에 대해서는 문서 페이지를 참조하세요.
회의 중 도출된 의견 및 피드백
제시된 의견과 피드백은 대략적으로 다음과 같습니다:
내부 노드 병목 현상(internal nodes and bottlenecks)
저장 속도가 중요(storage speed is critical)
블록 로그(bloks-log)는 작업 수, 동기화 관련 읽기 및 로컬 피어(reading and local peers) 우려
동기화 옵션 제한(limited syncing options)
대역폭 대 상태 범위(bandwidth vs. range of state) (충분한 대역폭과 피어 회전이 있다면 문제가 되지 않을 수도 있음)
마무리
회의는 다루어진 내용을 다시 명확하게 상기해보는 과정을 통해 마무리되었습니다. 대역폭 관리 전략으로 스로틀링(throttling )에 대한 질문이 있었습니다. 피드백에 따르면, 스로틀링은 피어를 연결 해제하는 대안으로 고려되고 있습니다.
개발팀은 노드 운영자들에게 다음 단계를 이끌어 나갈 수 있도록 협력을 요청합니다. 문서 페이지의 "기능/에픽(Features/Epics)" 섹션에 주목이 필요합니다. 여기에서 대역폭과 제어 메커니즘이 언급되었습니다.
6월 28일: 블록 트리밍, 립 5.0(Leap 5.0) 계획, IF, OC
6월 28일 회의에서는 블록 트리밍, 립 5.0을 위한 계획 수립, IF, OC 등에 관해 논의하는 시간을 가졌습니다.
개요
노드 운영자들은 현재의 블록 트리밍 프로세스에 관한 경험을 공유했습니다. 자동 진단, 자동화 및 여러 해결 방법에 대한 논의가 진행되었으며, 립 5.0의 계획과 준비에 대해 논의되었습니다.
업데이트
Leap 4.0에 대한 새로운 업데이트는 없습니다.
개발 팀은 5.0 출시 일정을 재작업하고 있습니다.
5.0에 대한 자세한 내용은 나중에 다시 다룰 예정입니다.
커뮤니티 건의사항
커뮤니티의 건의사항을 듣기 위해 모든 참석자들에게 발언 기회가 주어졌습니다. 토론은 현재의 4.0.3과 5.0에 대한 다양한 문제와 블록 트리밍에 대해 시작되었습니다. 블록-로그 예외(bloks-log exception)에 대한 솔루션을 정리하기 위해 "leap-util"을 사용하는 것에 대한 여러 의견이 제시되었습니다. 수백 개의 블록을 정리해야 하는 필요성은 개선될 여지가 있는 것처럼 보입니다. 오류(예외)를 식별할 수 있는 트리밍은 추가하면 좋은 기능이 될 것입니다.
더 깊게 논의된 주제들
이후 토론에서 두 가지 주제가 강조되었습니다:
"leap-util"의 형식과 내용(formatting and contents of leap-util (e.g. smoke test)
블록 로그의 롤백 필요성(need to roll back bloks-log)
아래는 회의에서 언급된 구체적인 사항들의 목록입니다. 목록 항목은 회의의 시간 및 전개 순서에 따라 나열되었습니다:
디스플레이 대 기능성(display vs. functionality)
최소한의 트리밍을 위한 잠재적인 개선 사항(potential improvements for minimum trimming)
안전한 솔루션 보장(ensuring a secure solution)
연속적 트리밍 추가 제안(suggested adding successive one-by-one trimming)
트리밍-진단 도구는 손상된 블록을 확인할 수 있을 것(a trimming-diagnostic tool could determine corrupt blocks)
자동 복구 솔루션(auto repairing solution that’s careful not to auto-remove blocks)
공개 노드 솔루션 대 개인 노드 솔루션(public vs. private node solutions)
스냅샷을 통한 완전한 수정은 공개 노드 대 개인 노드와 관련된 주의사항을 다시 언급합니다(complete fix via snapshot refers back to cautions concerning public vs. private nodes)
자세한 내용은 "leap-util is unable to successfully run a detailed smoke test and trim the blocklog. #1348."를 참조하세요.
립 5.0 계획 수립
이전에 언급한 대로, 립 5.0 출시 후보에 대한 계획수립이 시작되었습니다. 개발 팀은 합의 업그레이드에 관련된 오랜 시간이 걸리고 복잡한 프로세스를 정교하게 다듬기 위해 노력하고 있습니다. 립 5.0은 표준 절차를 수립할 것입니다. 9월에 롤아웃(rollout) 시작에 초점을 맞추고 있습니다.
립(Leap)은 앞으로 두 번의 주요 업데이트를 겪을 것으로 예상됩니다. 그 중 하나는 합의 업그레이드(하드 포크)를 필요로 할 것입니다. 노드 운영 비용을 줄이는 것이 주요 관심사 중 하나입니다. 이는 새로운 체인을 추가할 때 노드 운영자의 비용 감소를 포함합니다. 경험과 최적화(RAM, CPU 및 디스크 공간)의 이점에 대한 의견이 제시되었습니다. 4.0으로 업그레이드하는 데 더 많은 사람들이 참여하는 것의 중요성이 강조되었습니다.
5.0을 위한 두 가지 주요 프로토콜 업그레이드 기능은 다음과 같습니다:
IF(Instant Finality)
OC(Optimizing Compiler)
IF는 이 두 가지의 핵심적인 부분으로 보입니다. IF는 새로운 이오스(The New EOS)를 위한 ENF의 주요 이니셔티브입니다. OC는 주로 EVM 성능을 향상하기 위한 것이며, 그 외 일반적 이점도 제공합니다. 자세한 내용은 "Add eos-vm-oc-enable auto mode #1322"를 참조하세요.
마무리
회의는 5.0을 위한 OC 기능의 검토로 마무리 되었습니다. 현재 개발은 기본적인 개선 사항에 집중하고 있습니다. OC는 먼저 토큰 및 EOS EVM을 위한 eosio 시스템 계약에서 실행되어야 합니다. 앞으로는 새롭게 추가될 기능들과 립 5.0을 위한 정교한 사전 준비가 향후 회의의 주요 주제가 될 것으로 예상됩니다.