작성자: Marco González
편집자: Randall Roland
옮긴이: Sangyong Jeong
노드 운영자, Antelope 코어 개발자, 그리고 커뮤니티 구성원들은 매주 흥미로운 주제에 관해 논의합니다. 노드 운영자 라운드 테이블(EOS Node Operator Roundtable)의 주요 목표는 다음과 같습니다:
"노드 운영자들을 위해 Antelope 프로토콜을 개선하는 것"
회의는 매주 수요일 오후 UTC 14시부터 15시까지 진행됩니다. EOS 노드 운영의 기초를 배우고자 하는 분들을 위해, EOS Network Foundation은 튜토리얼과 문서를 제공합니다.
4월 19일과 26일의 라운드테이블에서는 Leap 개발이 주로 논의되었습니다. 4월 19일에는 Leap 버전 5.0에 대한 기대 및 비전에 대한 내용이 주를 이루었으며, 4월 26일에 v4.0.0이 출시되었습니다. 4월 마지막 라운드테이블에서는 피드백을 수렴하고 새로운 제안을 탐구했습니다.
4월 19일: Leap 5.0 너머의 기대와 그 비전
4월 16일의 회의록은 EOS Nation GitHub에서 확인하실 수 있습니다. ENF의 YouTube에서 녹화된 라운드테이블도 시청하실 수 있습니다.
개요
Antelope 5.0 버전은 며칠 후 출시될 예정입니다. 참여자들의 의견을 보고 자신의 의견을 공유하십시오. 몇 가지 업데이트가 있습니다:
Leap v4.0.0 출시
Antler 도구
CDT 데모
4월 19일 라운드테이블에서는 버전 5.0 이후 기대 및 비전을 탐구했습니다.
다음은 Brian Hazzard가 제시한 노트를 적용한 요약입니다. Antelope Leap 5.0 버전은 2023년 가을에 출시될 예정입니다.
EOS 메인넷의 버전 5.0은 커뮤니티의 미래와 비전을 대변합니다. 참가자들의 생각과 꿈을 각자 이야기할 수 있는 시간이 마련되었습니다.
오늘 날의 트렌드
비교적 쉽게 달성 가능한 작고도 영향력 있는 변화
실용적이고, 유용하며 일반적인 완화 조치
놀랍고, 논쟁적인 요소
뛰어난 포부
위의 소주제들은 5.0 (그 이상) 개발을 위한 바람을 일으켰습니다. 아래는 아홉 명의 참가자 각각의 간략한 요약입니다:
Ross : 동적 피어 탐색, 최상의 피어 자동화 및 마지막 블록 쉽게 확인
Daniel : 멀티체인 친화적, 유용한 이더리움 아키텍처 블록 및 The Graph 통합
Micheal : 더 자세한 관리 엔드포인트("GetInfo2") 및 안전 / 동기화된 노드를 나타내는 쿼리("Is Ready")
Marco (MachnBird Sparo) : 쉬운/접근 가능한 결제 처리 및 하드웨어
Aaron : 일시적 권한과 일치하는 규칙을 지정하는 권한
Kevin : 블록 유효성 검사 병렬화, 100K TPS 및 수평 스케일링
Denis : 통합 및 비용 효율성을 통해 기본 리소스 개선
Tony : 로키 통합을 위한 로깅 및 기본 모니터링 솔루션
J.P. : 운영 API를 통한 향상된 피어 관리 및 새로운 기능/수정 사항 쉽게 확인
전망
커뮤니티 피드백은 개발 방향성 설정에 있어 중요한 역할을 합니다. 5.0 개발 초기에 피드백을 제공하는 것은 큰 가치를 가져옵니다.
4월 26일: API/직렬화를 위한 nodeos 5.0 제안
Leap v4.0.0가 현재 적용되면서, 앞으로 몇 달간 5.0 개발을 위한 코스를 수정하는 것에 초점이 맞추어졌습니다. 4월 26일 회의록은 EOS Nation GitHub에서 확인하실 수 있습니다. (업데이트된) API/직렬화 시간 제약 조건에 대한 제안은 ENF hackmd.io 링크에서 찾을 수 있습니다. ENF의 YouTube에서 녹화본을 찾아보세요.
개요
논의는 Q&A 형식으로 진행되었습니다. 업데이트는 다음과 같습니다:
V4.0.0은 이번 주에 출시되었습니다.
CDT v4rc1은 다음 주에 공개될 예정입니다.
아래는 제안의 간략한 개요입니다. 5.0에서 곧 예상되는 변경 사항 중 두 가지 주요 요약은 다음과 같습니다:
ABI 직렬화 제한
non-atomic API 제한
대부분의 ABI (Application Binary Interface) 요청은 역직렬화를 HTTP 스레드 풀로 이동시켰습니다. 이 결과, nodeos의 주 스레드 응답성이 향상되었습니다.
결과적으로, non-atomic API에 반환되는 항목의 수에 제한이 발생했습니다. http_max_response_time에 대한 요청은 범위와 최대 시간을 지정해야 하며, 유효한 요청은 항상 적어도 하나의 객체를 반환하며, 기본 최대 항목 수는 1,000개입니다.
가이드라인:
API 노드는 모든 Atomic 요청을 성공적으로 처리합니다.
Non-atomic API 호출은 최대 요청 시간을 지정합니다.
사용자가 제공하는 "abi-bombs"으로부터 보호합니다.
get_block 변경
get_block 함수의 변경은 속도, 효율성, 그리고 메인 스레드를 멈추는 것을 방지하기 위한 것입니다.
모니터링
Prometheus는 history solution보다 추천되고 있습니다. Prometheus는 모니터링에 큰 도움을 줄 것으로 예상됩니다.
개발자를 위한 Use case
개발자가 플러그인을 사용할 수 있는 가능성에 대해 간략히 논의되었습니다. trace_api_plugin을 발전시키는 것과 레이어 2 솔루션에 대한 논의가 이어졌습니다.
다른 주제
실패(또는 멈춤) 이유
최대 응답 시간
history solution에 대한 추가 정보
스냅샷
전망
Leap 5.0은 성능 지향적 제안을 올바르게 처리할 것이고, 이는 5.0 개발의 원활한 진행에 큰 도움이 될 것입니다. 회의 참가자들은 단순히 빠르게 해결책을 제시하는 것보다도 좋은 품질에 중점을 두고 완벽을 지향하는 태도로 개발에 임하고 있습니다.