10월 18일: 립 5.0(Leap 5.0) 출시 예정: 초기 블록, 성능 향상 및 커뮤니티 의견

10월 25일: 노드 운영자 콜 포맷(Node Operator Call Format) 관련 논의, RC3에 도달하기 위한 마지막 목표

이날 회의는 립 5.0 출시에 대한 포괄적인 토론으로 시작되었습니다.

노드 운영자 커뮤니티 회원들은 RC2라는 초기 출시 후보 버전을 적극적으로 테스트하고, 공식 버전 출시 이전 발생할 수 있는 모든 문제를 식별하고 해결하기 위해 적극적으로 참여할 것을 강력히 권장했습니다.

CPU 백분율 옵션(CPU effort percentage option)에 중대한 변경 사항이 도입되었습니다.

이 제안은 CPU 옵션을 백분율 값 대신 밀리초로 구성하는 방식으로 전환하는 내용을 포함했습니다.

기존의 CPU 백분율, 마지막 블록 CPU(last block CPU effort), 마지막 블록 오프셋 및 마지막 블록 버전과 같은 옵션들은 "produce block offset ms"라는 새로운 옵션으로 대체될 예정이었습니다.

새로 도입된 "produce block offset ms" 옵션은 노드 운영자에게 12개 블록으로 이루어진 전체 라운드에 할당하고자 하는 밀리초 수를 지정할 수 있는 기능을 제공합니다.

이 오프셋은 블록 생산 지연을 처리하는 데 할당된 시간을 결정하는 데 중요한 역할을 합니다.

중요한 점은 이 변경이 합의 메커니즘에 영향을 미치지 않으며 블록 생산 효율성을 향상시키기 위해 고안된 것입니다.

이어서 립 5.0에서 조기 블록 생산을 도입하는 데 대한 토론이 진행되었습니다.

EOSUSA의 마이클(Michael)은 시스템 시간 설정을 변경하는 개념을 제시했는데, 이에 대한 잠재적 문제와 의도하지 않은 결과에 대한 우려가 있었습니다.

조기 블록 생산이 네트워크에 미칠 영향과 발생 가능한 문제에 관한 토의가 이어졌습니다.

케빈 하이프너(Kevin Heifner)는 조기 블록 생산으로 인한 잠재적 성능 향상에 대한 열정을 표현했습니다.

토론에서는 조기 블록 생산이 트랜잭션을 블록에 포함시킬 시간을 더 많이 제공함으로써 결국 네트워크 효율에 이바지하는 방법을 강조했습니다.

EOS VM OC (최적화된 컴파일러)가 특히 EOSIO DApps와 계약에 대한 중요한 성능 향상 도구로 인정받았습니다.

성능 향상으로 인해 부하가 증가할 가능성에 대한 주의가 역사적인 솔루션으로 전달될 수 있음을 언급했습니다.

이후 회의는 'produce block offset ms' 구성 및 기본값에 관한 주제로 이어졌습니다.

'produce block offset ms'의 기본값으로 450 밀리초가 제안되었으며, 토론에서는 기본 설정이 노드 동작에 미치는 영향의 중요성이 강조되었습니다.

특정 네트워크 조건과 일치하도록 설정을 조정할 수 있도록 허용하는 유연성이 핵심 요소로 강조되었습니다.

시간 동기화와 네트워크 지연이 늦은 블록에 미칠 잠재적인 영향이 다루어졌습니다.

케빈은 늦은 블록이 마이크로 포크(microforks)를 일으킬 수 있으며, 이 문제에서 시간 동기화가 어떠한 역할을 할 수 있을 지에 대해 언급했습니다.

토론은 '최대 트랜잭션 시간' 설정과 잠재적인 변경 사항을 포함했습니다.

케빈 하이프너는 "약 500 밀리초 정도"의 기본 설정을 권장했습니다.

'읽기 전용 창 시간' 설정을 구성하는 중요성이 강조되었으며, 성능 향상을 위한 네트워크 최적화를 강조했습니다.

개별 노드 운영자는 자신의 특정 사용 사례에 기반하여 이러한 값을 설정해야 한다는 것이 제안되었습니다.

온체인 합의를 통해 설정을 제어하는 개념이 네트워크 전반적인 구성 변경을 간소화하는 수단으로 소개되었습니다.

동등한 피어를 레이블링하는 데 관한 보류 중인 풀 리퀘스트(A pending pertaining to the labeling of peer-to-peer peers)에 대해 간단히 언급되었습니다.

이오스 스피어(EOS Sphere)의 로스(Ross)는 기술 팀으로부터 얻은 인사이트를 높게 평가했습니다.

샤크(Shaq)는 립 업데이트 정보와 기술적 인사이트의 필요성을 강조했습니다.

EOSUSA의 마이클(Michael)은 협력이 소프트웨어 성숙도에 미치는 영향을 인정했습니다.

OCI의 케빈 하이프너(Kevin Heifner)는 실제 노드를 운영하는 노드 운영자로부터의 피드백 중요성을 강조했습니다.

향후 회의 관련 문서를 포함하는 논의.

프로토콜, 노드 운영자 및 개발자 문서를 포함한 문서 규격화.

진화하는 기능과 잠재적인 변경 사항 고려.

다가오는 기능에 대한 깊은 탐구.

특정 주제에 대해 긴급한 회의 소집 및 진행에 대한 아이디어 논의가 이루어졌으며, 참가자들은 이러한 방식이 가치 있을 지에 관해 토론했습니다.

이러한 형식으로 전환할 경우 개발자 중심 회의로 전환되어 노드 운영자가 참여하지 않을 수 있다는 우려가 제기되었습니다.

참가자들은 때때로 이오스 네트워크의 주요 개발자(예: Nathan James)들이 이러한 콜에 참여하길 원한다는 의사를 표현했습니다. 케빈 하이프너(Kevin Heifner)를 개발자 회의에 초청하고 네이선(Nathan)의 전문 지식을 문서 작성 및 지향에 활용하는 양방향 교환 개념이 제안되었습니다.

참가자들이 구상한 노드 운영자 회의의 드림 팀은 케빈 하이프너(Kevin Heifner), 네이선 제임스(Nathan James), 그리고 정기 기여자들(Michael EOSUSA, 로스(EOS Sphere), 매튜 다윈)로 이뤄지며, 애런 콕스(Aaron Cox, 팀 그레이매스)와 같은 인프라 중심 노드 운영자, 그리고 EOS 암스테르담의 스탠(Stan)과 같은 L2 전문가가 포함되어야 한다는 의견이 주를 이루었습니다.

주간 일정을 유지하는 것이 중론입니다.

회의를 일관된 1시간으로 유지하는 제안이 있었습니다.

심층 토론을 위한 연장을 고려하고 있습니다.

일상적인 루틴을 방해하고 참여를 분산시킬 위험이 있다는 우려가 제기되었습니다.

다양한 시간에 추가적인 콜 제안이 있었습니다.

상태 업데이트와 주요 주제를 포함한 유연한 안건이 있어야 한다는 제안이 있었습니다.

회의를 적절하게 기록하고, 회의에 참여하지 않은 노드 운영자로부터 피드백을 얻는 것이 권장되었습니다.

회의 녹화에 대한 우려는 없습니다.

활성 녹화에 조건이 있는 경우 AI 생성된 메모를 환영합니다.

최종 주제는 참석 증대에 관한 것이었으며, 이 중요한 토론에 참여를 확대하기 위해 결석자들을 적극적으로 참여시키는 제안이 있었습니다.

트랜잭션 서명을 위한 CPU 가용성에 중점이 둬졌으며, 특정 구성 매개변수인 "produce block offset"과 이를 최적화하기 위한 전략에 특별한 언급이 있었습니다.

마일스톤이 개요로 설명되었는데, 다음 릴리스 후보에 대한 문제 해결에 중점이 둬졌습니다. ARM 빌드에서 BLS 테스트가 실패하는 등의 중요한 문제가 논의되었고, 현재 이러한 문제를 해결하기 위한 작업이 진행 중이라고 언급되었습니다.

매개변수의 건강한 설정은 중요한 주제였으며, 이에 관한 질문이 로스로부터 제기되었고, 케빈이 이에 대한 자세한 설명을 했습니다. 이 설정이 다가오는 릴리스에서 어떻게 개선될 것인지에 대한 설명이 있었습니다.

RC2에서는 기본값이 90% 또는 600 밀리초로 설정되었는데, 이는 너무 보수적으로 여겨졌습니다. 새로운 릴리스에서는 오프셋을 밀리초로 표현하도록 새로운 설정이 도입되어 더 세밀한 조정이 가능해졌습니다. 참가자들은 여러 설정과 개선된 트랜잭션 처리 및 지연 시간 감소와 같은 잠재적 이점에 대해 논의했습니다.

EOS Support Learning Center