작성자: Marco González
편집자: Randall Roland
옮긴이: Sangyong Jeong
노드 운영자, 안텔로프(Antelope) 코어 개발자, 그리고 커뮤니티 구성원들은 매주 흥미로운 주제에 관해 논의합니다. 노드 운영자 라운드 테이블의 주요 목표는 다음과 같습니다:
"노드 운영자들을 위해 Antelope 프로토콜을 개선하는 것"
회의는 매주 수요일 오후 UTC 14시부터 15시까지 진행됩니다. EOS 노드 운영의 기초를 배우고자 하는 분들을 위해, EOS Network Foundation은 튜토리얼과 문서를 제공합니다.
특수 목적 노드에 관한 논의는 재차 연기되었습니다. 대신, 안텔로프(Antelope) 코어 개발자들은 4월 05일과 12일 라운드테이블에서 각각 Leap 4.0과 5.0에 대한 통찰을 공유했습니다. 핵심 개발자들은 관련 진행사항을 커뮤니티에 제공하고 피드백을 얻고자 했습니다.
4월 5일: Antelope v4.0.0 업데이트 및 피드백
이번 주 회의에서는 ENF 코어 개발자들의 v4.0.0에 대한 통찰과 관련 피드백이 중점적으로 논의되었습니다. Brian Hazzard는 4월 05일 노트를 언급했으며, 이를 EOS Nation GitHub에서 확인할 수 있습니다. ENF의 YouTube에서 녹화된 라운드테이블 회의를 확인해보세요.
개요
Antelope v4.0.0은 EOS의 성능, 확장성, 신뢰성을 더욱 발전시킬 것입니다. 제공될 기능들은 다음과 같습니다:
멀티스레딩을 통해 더 높은 성능을 제공합니다.
지연 시간을 줄이고 빠른 블록 전파를 가능하게 합니다.
더 많은 데이터 제어와 가시성을 제공합니다.
노드 운영자들을 위한 전반적 사용성 개선을 제공합니다.
Brian이 언급한 구체적 요약은 다음과 같습니다:
4배 더 빠른 get_block, 더 이상 주 스레드에서 작동하지 않습니다.
nodeos 전체에서 JSON 파싱 속도가 2배 더 빨라졌습니다.
멀티스레드, 읽기 전용 윈도우를 사용하여 전반 사용성을 개선합니다.
Lin Huang: 읽기 전용 트랜잭션
Brian의 브리핑 이후 Lin Huang의 프레젠테이션이 이어졌습니다. 읽기 전용 트랜잭션 활성화를 위한 준비 과정으로 Lin은 다음과 같은 내용에 대해 논의했습니다:
새로운 RPC 엔드포인트
사용자 실수 방지를 위한 non-modified state actions
authorizations/signatures 금지
항상 트랜잭션 추적(Trace) 정보 반환
Tracking 및 Trace Logging을 위한 별도 트랜잭션
Deep-mind Logging
Lin은 < /cleos push transaction >를 통해 읽기 전용 트랜잭션에 관한 내용을 발표했습니다. 병렬 읽기 전용 트랜잭션(및 작업)의 주요 기능은 다음과 같습니다:
read-only: 병렬 실행 가능
read-write: 병렬 실행할 수 없음
read window: 읽기 전용으로만 실행 가능
write window: 읽기 전용 및 읽기/쓰기 모두 실행 가능; 메인 스레드에서 순차적으로 실행 가능
구성
Vlad: 스냅샷 스케줄링(Snapshot Scheduling) 및 개선점
Vlad가 발표한 스냅샷 스케줄링의 주요 사항은 다음과 같습니다:
스냅샷 스케줄링 for one-time future and recurring
위 작업 수행을 위한 3 API 호출 (snapshot_requests)
JSON 파일로 저장
그는 주기적인 스냅샷을 "가장 흥미로운" 기능으로 설명했습니다. 스냅샷은 매 20개 블록마다 생성되며 블록 생성이 종료될 때까지 계속됩니다. 임의 스냅샷은 ID로 수행할 수 있습니다.
Vlad는 또한 새로운 도구(leap-util)가 현재 새로운 기능을 추가하고 업데이트된 /cleos를 지원할 것이라고 언급했습니다.
Peter Oschwald: 퍼포먼스 하네스(Performance Harness)
Peter Oschwald는 보고서를 통해 퍼포먼스 하네스(일종의 성능 평가 도구)에 대한 설명 및 개념을 상세히 제공했습니다. 다양한 운영 노드에 대한 성능 측정을 보다 효율적으로 수행하기 위한 방법을 제공하고자 초기에 고안되었습니다. 개발자는 이를 통해 생태계 전반의 성능 개선이 실제로 어떻게 이루어지는 지 확인할 수 있습니다.
Peter는 퍼포먼스 하네스의 세 가지 다른 레이어(simple, basic, and advanced)를 설명했습니다. 레이어가 더 상위 단계일수록 더 많은 매개변수를 사용합니다. 퍼포먼스 테스트 베드 및 일반적 구성에 대한 자세한 정보는 Pefromance_tests README [video 31:12 참조]에서 확인할 수 있습니다.
Peter는 연관 플러그인 대체품인 트랜잭션 생성기(transaction generator) 및 대량 TPS 처리에 대해 설명한 후 더 많은 기능을 소개했습니다. 또한 노드 성능 개선 및 저하 측정 계획을 암시적으로 언급하기도 했습니다.
Kevin Heifner: 성능, 지연 시간, 데이터 및 전반 사용성
회의를 마무리하기 전 Kevin Heifner는 몇 가지 주제를 간단하게 개괄하였습니다. Brian의 노트를 사용하여, Kevin은 네 가지 큰 개선 분야와 그 하위 항목을 개괄했습니다.
높은 성능
읽기 전용 트랜잭션 및 작업 실행 병렬화(read-only transaction and task execution)
멀티스레딩 및 스레드 안정성
http_plugin 최적화
주관적 CPU 개선
낮은 지연 시간
스케줄된 proximal BP nodes 및 자동 피어링
릴레이용 낮은 수준의 검증(Lighter validation)
데이터 통제 및 시각화
Prometheus 내보내기 도구
블록 및 SHiP용 로그 분할
전반 사용성
리소스 모니터의 절대 값(Absolute value) 설정
nodeos 플러그인 전체에서 개선된 로깅
Kevin은 자동 피어링이 현재 어떻게 작동하는지 테스트했으며, 관련 테스트는 BP 스케줄링과 관련된 연결성을 다루었습니다.
또한 그는 Prometheus 내보내기 플러그인(Prometheus exporter plugin)에 대해 몇 가지 참고 사항을 제공했습니다.
IPv4는 플러그인이 활성화되면 별도의 포트에서 수신 가능하게 만듭니다.
IPv6는 5.0에서 사용 가능합니다.
로그 분할(다른 상태 디렉터리 지정)
회의를 마무리하며, nodeos가 (retain) 디렉터리에 액세스하지만 아카이브에는 액세스하지 못한다는 언급이 있었습니다. 상태 기록(Status History) 또한 관련 문제가 관측되었습니다.
Kevin은 get_block의 약 4배 빠른 속도 개선으로 블록 전파가 4.0 환경에서 훨씬 빨라질 것을 언급하며, "그냥 단순하게 말하면, 더 빠릅니다"라고 덧붙였습니다. 그는 프로세스(time)의 절반 이상이 주 스레드에서 감소할 것으로 예상합니다.
전망
EOS는 가장 빠른 속도의 블록체인 중 하나입니다. Antelope의 v4.0.0 개발은 EOS를 더 빠르고 더 효율적이며 개발자 사용성을 극대화할 것입니다.
4월 12일: 5.0 환경 및 엔드 포인트 카테고리 개괄
Antelope의 핵심 개발자들은 5.0 환경에 대한 비전을 제시하고 피드백을 요청했습니다. 기존 운영과 4.0 환경, 그리고 5.0 환경을 비교하며 이야기가 진행되었습니다. 4월 12일 라운드테이블 노트는 EOS Nation GitHub에서, 그리고 비디오는 ENF의 YouTube에서 확인하실 수 있습니다.
업데이트
v4.0.0-r3 출시
CDT-rc1 곧 출시 예정(아마도 다음 주).
개발자 오피스 아워
v4.0.0-rc3로 새롭게 추가될 기능을 제공된 링크에서 자세히 확인하세요.
Stephen Diesel이 주도하는 개발자 오피스 아워가 진행될 예정입니다. 첫 번째 미팅은 4월 20일 시작되며 매주 목요일마다 진행됩니다. CDT와 기타 개발 관련 사항(DUNE, 문제점 및 새로운 Antler pods 등)에 대해 더 알고 싶다면 텔레그램에서 Stephen에게 문의해 보세요.
개요
5.0 합의 업그레이드는 초가을 즈음으로 예정되어 있습니다. 잠재된 불확실성을 고려하여 이번 미팅은 전체 프레임에 관한 논의가 주로 이어졌습니다.
5.0에 필요성 기능
관련 제안 검토
Prometheus 플러그인
엔드 포인트 카테고리
주요 의제
4.0에서 Prometheus 플러그인이 도입될 예정입니다. 짧은 테스트 기간 동안 커뮤니티 회원들은 플러그인을 별도로 구성 가능한 포트에서 실행할 수 있도록 요청해 왔습니다. 이제 그것이 5.0의 주요 목표로 보입니다.
별도의 엔드포인트에서 Prometheus를 실행하는 것이 다른 엔드포인트 구성하는 것보다 효율적이라는 의견이 모아졌습니다. 제안된 몇 가지 엔드포인트 범주는 다음과 같습니다:
get_info
chain_ro
chain_rw
net_ro
net_rw
producer_ro
producer_rw
snapshot
trace_api
Prometheus
node
의미 있는 방식으로 각 엔드포인트는 그룹화될 것입니다. 기본 옵션은 모든 엔드포인트가 하나의 카테고리에 있도록 설정됩니다.
“custom port/io configurations” 제안이 공유 및 검토되었습니다.
5.0의 주요 우선 과제로 IPv6 도입이 언급되었습니다.
피드백
효율적인 엔드포인트 카테고리 아이디어는 좋은 반응을 얻었습니다. 이후 여러 주제에 관한 피드백과 응답이 이어졌습니다:
get_supported_apis에 대한 새로운 구성 (카테고리)에 대한 의견
커넥션 필터링 프로세스
get_server_info 및 get_info에 관한 논의
현재 get_info는 일반적으로 공개되어 있습니다. 그러나 피어 환경 (예: 프로듀서 노드)에서는 get_info가 비공개로 유지되어야 합니다.
모든 엔드포인트에 get_info를 유지하는 것에 대한 강력한 논의가 있었습니다.
마무리
라운드테이블은 catchup 모드와 구성 한계에 관한 논의로 마무리되었습니다.
Brian은 5.0에서의 이상적 환경에 대한 피드백을 구하며 회의를 마무리했습니다. 제안할 수 있는 몇 가지 분야를 제시했지만, 피드백은 특별한 제한 없이 언제나 열려 있다는 점을 강조했습니다:
pain points
special items
improving performance
meaningful new capabilities
driving adoption
carving out a niche
개요
EOS 네트워크는 이제 EOS EVM을 통해 이더리움 네트워크와 연동되었습니다. EOS의 성능을 더욱 극대화하기 위한 4.0 및 5.0 버전에 대한 준비가 속도감 있게 진행되고 있습니다. 두 버전 모두 전반적 기능을 개선할 것입니다. EOS는 본래의 이상 실현을 위해 계속 나아가고 있습니다.