작성자: Marco González
편집자: Randall Roland
옮긴이: Sangyong Jeong
노드 운영자(Node Operator), 안텔로프(Antelope) 핵심 개발자, 그리고 다양한 커뮤니티 구성원은 네트워크 발전을 위한 건설적이고 흥미로운 주제에 대해 논의합니다. 노드 운영자 회의(Node Operator Roundtable)의 목표는 다음과 같습니다:
"노드 운영자들을 위해 안텔로프 프로토콜을 개선하는 것"
회의는 매주 수요일 오후 UTC 14시부터 15시까지 진행됩니다. 이오스 노드 운영의 기초를 배우고자 하는 분들을 위해, EOS 네트워크 재단(EOS Network Foundation, 이하 ENF)은 관련 튜토리얼 및 문서를 제공하고 있습니다.
다음은 이번 달 진행된 회의의 간략한 개요입니다:
7월 19일: 5.0 버전을 위한 구성(Configuration) 변경 권고
7월 26일: 회의가 취소됨.
깃허브(GitHub)에서 해당 회의록을 확인하시고, ENF 유튜브 채널에서 녹화 비디오를 확인하세요.
7월 19일: 5.0 버전을 위한 구성(Configuration) 변경 권고
7월 19일 회의는 노드 운영자 커뮤니티가 안텔로프 v4.0에서 v5.0으로 초점을 전환하는 지점이 될 것입니다. 립 5.0(Leap 5.0) 런칭을 준비하기 위한 조치로서 구성 변경에 대한 논의가 진행되었습니다.
개요
에릭 패스모어(Eric Passmore)는 ENF가 제시한 구성 변경 권장 사항을 요약했습니다. 이는 아래 문단에서 중점적으로 다룰 것입니다.
에릭은 최근 블록원(Block.one, 이하 B1)이 버전 2.0을 출시한 것에 대해 언급하며, 구성 변경은 여러 측면에서 의미가 있다고 설명했습니다. 변경 권장 사항은 성능 테스트와 경험적 데이터 모두를 기반으로 제시되었습니다.
7월 18일 노드 운영자 텔레그램 채널에 게시된 권장 사항
첫 번째 권장 사항은 30ms를 초과하는 프로덕션 환경(production environment) 내 트랜잭션입니다. 여기서 립 4.0(Leap 4.0)에 추가된 읽기 전용(read_only) 트랜잭션 업데이트가 눈에 띕니다. 제한을 증가시킴(Increasing limits)으로써 읽기 전용 및 일반적 프로덕션 환경 내 트랜잭션에 모두 이점이 있을 것입니다.
구성 변경에 관한 ENF 권장사항은 다음과 같습니다.
1. 읽기 전용 구성 변경은 립 4.0 이상의 버전에만 유효합니다:
"(165ms) read-only-read-window-time-us를 165,000으로 변경"
"(151ms) max-transaction-time을 151로 변경"
2. 멀티시그(Multisig) 변경은 현재 정글 테스트넷(Jungle testnet)에만 영향을 미치고 있습니다. 메인넷(mainnet)은 아직 변경이 필요하지 않습니다:
"(150ms) max_transaction_cpu_usage를 150,000으로 변경"
"(200ms) max_block_cpu_usage를 200,000으로 변경"
주간 노드 운영자 회의와 조정된 롤아웃(rollout) 계획이 함께 진행되기 전까지 제안된 변경 사항은 주로 테스트넷에 초점을 맞추어 진행될 것입니다.
이러한 변경 제안은 버전 5.0의 기본 구성(default configuration)보다 앞서 진행됩니다. 에릭은 그의 게시물을 통해, 업그레이드 전 블록 생산자(Block Producer)와 체인(Blockchian Network)이 동일한 설정을 구성하도록 하고, 이는 버전 5.0 업그레이드를 차질 없이 잘 진행되도록 하는데 도움이 될 것이라고 말했습니다.
논의
에릭은 구성 변경과 관련된 내용을 논의하기 위해 노드 운영자 회의에 참석했습니다. 커뮤니티는 ENF가 어떠한 의도를 가지고 이를 권장하는 지에 대해 충분히 이해했으며 이의를 제기하는 노드 운영자는 없었습니다.
간단히 논의된 주제는 다음과 같습니다:
시간 명확화(time clarifications)
30ms 151ms로 증가하여 충분한 여유 시간 제공(increasing from 30 to 151 milliseconds provide ample breathing room)
새 변경 사항을 정글 테스트넷에서 약 2주간 시험(expect a couple of weeks of testing on Jungle for new changes)
업그레이드 조율의 원활함은 구성 변경으로부터 시작될 것(emphasis on smooth coordination begins with configuration changes)
트랜잭션 실패와 주관적 청구(sufficiency of subjective billing for transaction failures)
'주관적 청구'는 CPU 비용 및 구성 변경을 기반으로 '실패한 트랜잭션'을 방지하는 데 도움이 될 것입니다.
이오스 네트워크(EOS Network)의 모든 활동을 완벽하게 시뮬레이션하는 것은 불가능합니다. 계획된 변경 사항이 수정되어야 할 수도 있습니다. 더욱 신중히 고려해야 할 사항은 무엇이 잘못될 수 있는지에 대한 것입니다(특히 블록 프로듀서와 관련하여).
5월 24일 블로그 글 "주관적인 청구 및 분실 트랜잭션"에서도 여러 차례 노드 운영자들이 언급되었습니다.
구성 변경과 관련된 다른 주목할만한 언급으로는 성능/벤치마크(performance/benchmark) 테스트가 있습니다.
버전 5.0, 주관적 청구, 블록의 더 빠른 처리
안텔로프 립 5.0은 어떻게 블록을 더 빨리 처리하게 될까요? 5월 24일 게시물의 주관적인 청구에 관한 내용에 따르면:
"만델(Mandel) 3.1의 새로운 기능을 통해 노드 운영자는 초기화 시 노드의 주관적인 청구 소멸 시간 매개변수를 설정할 수 있습니다. 이 옵션은 계정의 주관적인 청구서를 0으로 만드는 데 걸리는 시간을 조정합니다."
8월 8일 게시된 "Leap v3.1 릴리스 기능 및 추가 도구"에서는 새로운 트랜잭션 라이프사이클 도구(Transaction lifecycle tools)들이 소개됩니다:
주관적 청구 시스템이 버전 5.0에서 성숙함에 따라 뚜렷한 개선이 기대됩니다. 미적용되거나 대기 중(unapplied, queued)인 트랜잭션 대신 다음 블록이 즉시 시작될 수 있습니다. 심지어 한 라운드에서 12개의 블록을 완료하는 것이 제안 되기도 했습니다. 마지막 블록에 대한 제어 고려가 환기되었습니다.(Caution was given for control consideration of the last block).
회의는 버전 5.0를 기대하는 커뮤니티의 열망 속에서 일찍 종료되었습니다.
출처 및 참고문헌