메인 콘텐츠로 건너뛰기
모든 콜렉션이오스(EOS) 관련 소식
노드 운영자 회의 요약 [2023년 7월 #1]
노드 운영자 회의 요약 [2023년 7월 #1]

2023년 7월 21일 발간

Sangyong Jeong avatar
작성자: Sangyong Jeong
최소 1년 전에 업데이트됨

작성자: Marco González

편집자: Randall Roland

옮긴이: Sangyong Jeong



노드 운영자(Node Operator), 안텔로프(Antelope) 핵심 개발자, 그리고 다양한 커뮤니티 구성원은 네트워크 발전을 위한 건설적이고 흥미로운 주제에 대해 논의합니다. 노드 운영자 회의(Node Operator Roundtable)의 목표는 다음과 같습니다:

"노드 운영자들을 위해 안텔로프 프로토콜을 개선하는 것"

회의는 매주 수요일 오후 UTC 14시부터 15시까지 진행됩니다. 이오스 노드 운영의 기초를 배우고자 하는 분들을 위해, EOS 네트워크 재단(EOS Network Foundation, 이하 ENF)은 관련 튜토리얼 및 문서를 제공하고 있습니다.

다음은 이번 달 진행된 회의의 간략한 개요입니다:

  • 7월 5일: 효율성과 안정성: 교통, 블록 크기/시간 및 SHiP

  • 7월 12일: 다중 액션 승인((Multi-action Authorizations))에 대한 사용자 친화적인 해결책과 립 5.0

깃허브(GitHub)에서 해당 회의록을 확인하시고, ENF 유튜브 채널에서 녹화 비디오를 확인하세요.

7월 5일 회의:

효율성과 안정성: 트래픽, 블록 크기/시간, 5.0, 그리고 SHiP

립 5.0(Leap 5.0) 업데이트 일정이 점점 가까워짐에 따라 회의는 열린 토론 형식으로 진행되고 있습니다. 노드 운영 안정성을 담보하며 5.0 업데이트 일정을 조율하는 것은 쉽지 않은 과제입니다. 2023년 가을에 이루어지는 합의 업그레이드가 얼마나 원활하게 진행될지는 커뮤니티의 의견 모니터링, 개발 업데이트 공유, 그리고 의사소통에 따라 달라질 것입니다.

7월 5일에는 커뮤니티의 관심사가 블록 크기와 시간(block size and times)에 집중되었습니다.

개요

높은 트래픽에 대한 논의, 블록 크기/시간, 5.0, 그리고 SHiP 문제에 대한 토론은 효율성과 안정성을 특징으로 합니다. 립 5.0이 다가오는 과정에서 조화로운 분위기가 계속되고 있습니다.

업데이트

  • 세부 내용이 포함된 패치가 곧 제공될 예정입니다.

커뮤니티 주제: 효율성과 안정성

해당 토론은 주로 효율성과 안정성에 초점을 맞추었습니다. 네트워크 성능과 교통, SHiP,(State History Plugin, 상태 히스토리 플러그인) 블록 크기, 처리 시간, 그리고 Leap 5.0 개선 사항과 같은 세부 사항들이 검토되었습니다. 또한 API 처리 중 충돌을 피하는 방법에 대한 링크도 참고하시기 바랍니다.

트래픽

노드 운영자 회의의 주요 초점은 이오스 네트워크(EOS Network)이지만, 일반적으로 회의에서는 모든 퍼블릭 안텔로프 블록체인(Public AntelopeIO Blockchain)에 대한 토론이 가능합니다. 현재 가장 높은 트래픽을 갖는 체인 중 하나는 왁스 블록체인(WAX)입니다.

왁스 블록체인의 많은 트래픽은 노드 운영자들을 한계까지 밀어붙입니다. 왁스 블록체인의 트래픽 문제에 관한 토론은 이오스, 왁스 및 기타 안텔로프 체인의 발전에 분명한 도움을 줄 수 있을 것입니다.

왁스는 직면한 문제들로 인해 립 버전 4.03을 구현하는 데 어려움을 겪고 있습니다. 버그 리포트가 지속적으로 발생하는 상황에서 테스트가 계속 진행 중입니다. 실제 부하 테스트 또한 고려되고 있습니다. 립 버전 5.0은 현재 4.0 환경에서 가능한 성능보다 훨씬 더 뛰어난 성능을 갖추기 위한 준비를 하고 있음을 참고해 주세요.

블록 크기/시간과 립 5.0

블록 크기는 여전히 큰 관심사입니다. 이오스 블록체인이 처음 시작되었을 때, 최대 CPU 블록 시간은 100 밀리초로 설정되었습니다. 이후 블록 시간이 250 밀리초로 증가되었고, 현재는 다시 200 밀리초로 설정되었습니다. 립 5.0에서는 250 밀리초로 복귀합니다. 이제 트랜잭션을 훨씬 더 빠른 속도로 처리할 수 있는 능력을 갖추게 될 것입니다.

다른 주제와 우려사항으로는 다음과 같은 것들이 제기되었습니다:

  • 블록 크기에 대한 가변적 구성(variable configuration for block size)

  • 병목 현상(bottlenecks)

  • 트랜잭션 실패 및 평가 시간(transaction failure and evaluation times)

  • 네트워크 처리량(network throughput)

  • 화이트리스트 및 계정 티어 업그레이드(whitelists and account tier ups)

  • 고정된 시간 vs. 가변 시간(set times vs. percentage time)

립 5.0은 고유한 이점을 통해 노드 운영의 패러다임을 변경하고자 합니다. 다음과 같은 세부 사항을 살펴보세요:

  • 항상 가장 작은 블록 시간을 선택합니다.(always chooses the smallest block time)

  • 밀리초 오프셋 vs. 블록 세트(millisecond offsets vs. block sets)

조기 블록 완료는 종료 시간이 동일하더라도 더 빠르게 블록을 시작할 수 있도록 하는 것을 의미합니다.

5.0에서는 4.0보다 더 빠른 블록 시작을 가능하게 할 것이지만, 개발 팀은 여전히 4.0의 기존 능력을 확인하고자 합니다.

5.0에서는 처리 중인 트랜잭션이 간혹 중단되는 문제가 해결되었습니다. 앞으로 테스트를 거쳐 조정될 가능성이 있으며, 핵심 노드 운영자들은 가을 출시를 앞두고 조속히 테스트를 시작하고자 합니다.

SHiP 문제

새로운 패치 릴리스로 최근 SHiP (State History Plugin, 상태 히스토리 플러그인) 문제가 해결될 것으로 기대됩니다. 커뮤니티 피드백에 따르면, SHiP으로부터의 피어 연결 부재가 주요한 원인으로 식별되었으며, 스냅샷이 유용할 것으로 예상됩니다. 이러한 변화는 제네시스(Genesis)에서 동기화하는 데 도움이 될 것입니다. 또 다른 확인된 문제는 ABI 데이터를 받지 못하는 것이었습니다. 이러한 문제들을 다음 패치에서 해결할 수 있을 것으로 기대됩니다.


곧 관련 패치의 출시를 염두하세요.

7월 12일 회의:

다중 액션 승인에 대한 사용자 친화적인 해결책과 립 5.0

7월 12일의 회의에서는 동적 애플리케이션(Dynamic applications)에 대한 탐구가 주로 진행되었습니다. 보안과 관련된 수정 사항이 반영되었으며, 립 5.0을 위한 초기 준비가 다음 몇 주 안에 시작될 수 있습니다.

개요

동적 애플리케이션은 항상 사용자의 입장에서 고려되어야 합니다. 특히 다중 액션 승인에 대한 해결책은 지갑 및 노드 운영자의 입장에서 고려되어야 합니다. 다중 액션 승인을 위한 지갑 해결책은 그 중에서도 특히 가치 있는 솔루션이 될 것입니다.

업데이트

  • 립 버전 4.0.4, 3.2.43.1.5에 대한 일련의 패치 릴리스가 출시 예정입니다.

이 버전은 여러 보안 취약점에 대응합니다. 각 수정 사항에 대해 더 자세한 내용은 관련된 버전 링크를 확인하시기 바랍니다(안정성 해결책을 포함하여).

다중 액션 승인에 대한 사용자 친화적인 해결책

블록체인 사용자들은 기존 익숙한 웹2과 유사한 사용자 경험과 함께 그들의 자산을 스스로 관리하고 제어할 수 있어야 합니다. 지갑 해결책을 고려하는 동적 승인 방식이 가장 효과적인 조치로 판단됩니다.

이번 회의에서 고려된 다중 액션에 포함된 기능 목록은 다음과 같습니다:

  • 만료 옵션(an expiry option)

  • 사용자에게 특정한 체인 상에 저장된 승인에 대한 토큰형 영수증(receipt for on-chain saved authorization specific to users)

  • 위임된 스마트 계약 권한(delegated smart contract permissions)

  • 가변 옵션에 대한 공통 표준(common standards for variable options)

  • 화이트리스팅(whitelisting)

  • 승인 요청(request-for-permission) RFP

그 중에서도 만료 옵션과 화이트리스팅이 가장 큰 관심사를 끌었습니다. 해결책은 핵심 코드 변경을 통해 가능할 수 있지만, 신뢰할 수 있는 지갑 해결책을 처음으로 채택하는 것이 현명한 첫 번째 단계로 보입니다.

예를 들어, RFP는 지난 스캐터(Scatter) 기능과 유사한 지갑 중심의 해결책과 잘 작동할 수 있습니다. 그러나 트랜잭션 일정과 비동기식 지갑/애플리케이션 특히 게임 종료에 있어서 발생할 수 있는 우려가 제기되었습니다.

회의 참가자 중 한 명이 채팅에서 "화이트리스팅과 승인한 목록의 차이점이 무엇인지" 언급했습니다. 해당 참가자는 운영자가 다음을 포함할 수 있는 해결책을 설명했습니다:

"네임스페이스(.ra)를 사용하여 사용자의 공개 키로 새로운 계정 등록하는 방법이 일반적인 접근 방법일 것입니다."

모든 해결책 구현을 고려할 때 사용자가 생각하는 관점이 기술자가 생각하는 측면과 다르다는 점을 반드시 고려해야 합니다. 회의 참가자들은 해당 해결책 구현에 있어 기존의 전통적인 웹 승인 방식과 비교한 사용자 기대치를 설명했습니다. 사용자는 개발자가 구현하기에 더 복잡할 수 있더라도 추가적인 블록체인 계정이 추가되는 것보다는 하나의 계정을 유지하길 원할 수 있습니다. 이에 다시 지갑과 관련한 여러 기능들이 제안되었습니다.

회의 관리자는 다른 주제로 립 5.0과 관련한 즉각적 최종성(IF)과 합의 실패 문제(consensus-breaking issues)에 대한 주제를 제안했습니다. 현재 회의의 다른 주요 주제들목록입니다.:

  • 합의 프로토콜 업그레이드 조정(coordinating a consensus protocol upgrade)

  • 화이트리스팅 vs. 계정 권한에 대해 더 자세한 내용(more about whitelisting vs. account temporal aspects permissions)

  • 만료 옵션을 위한 새로운 공개 키 (보안 관련 우려 제기) vs. 지갑 로그인 인식(a new public key for expiry options security concern raised vs. wallet login recognition)

  • 현재 지갑이 키를 저장하고 응용 프로그램을 저장하지 않는 점에 대한 주목(notation made about wallets currently storing keys and not applications)

  • 모바일 애플리케이션은 eosio 레벨에서 고유한 만료 옵션과 제어 제한이 필요할 수 있음 (mobile applications may need unique expiry options and control limits at the eosio level) e.g: 시장 판매를 위한 프리미엄 이름 권한

  • "... 자신의 권한을 제거하는 권한..."(asked in chat: “...permission to remove its own permission…”)

몇 가지 아이디어로 끝으로 회의가 마무리되었으며, 회의 참가자들에게 항상 목표를 염두에 두고 최신 정보를 지속적으로 확인할 것(예: 패키지 매니저), 맞춤 개발 도구를 용이하게 하는 것, 기본 문서의 중요성 등이 강조되었습니다.


출처 및 참고문헌

답변이 도움되었나요?