EOS Node Operator Round Table Week 1 ~ 10 요약정리

Junhan Kim
NodeONE
Published in
7 min readDec 5, 2022

ENF 와 일부 BP 및 관계자들은 연초부터 매주 수요일에 모여 9월 28일의 EOS 컨센서스 업그레이드를 위한 테크니컬 미팅을 가졌습니다. 컨센서스 업그레이드는 성공적으로 마무리 되었지만, 이후로도 계속해서 주요 멤버들이 Antelope 의 방향성과 미래와 관련된 중요한 이야기들이나 테크니컬 이슈들을 매 주 미팅에서 논의하고 있습니다. 블록체인 개발자나 노드 운영자 같은 엔지니어분들이 한번은 눈여겨볼 만한 주제들 입니다.

노드원에서는 금주 부터는 가능한 매주 혹은 격주로 미팅에서 논의되는 이야기를 정리하여 공유 드리도록 하겠습니다.

먼저 컨센서스 업그레이드 이후 지금까지의 10주간 진행된 내용을 회의록을 참고하여 아주 간략하게 요약하여 공유드립니다.

2022/12/05 현재 소프트웨어 개발 상황

  • Leap 3.2 Final Release 가 공개 되었습니다.
  • DUNE(Docker Utilities for Node Execution) 의 새 버전이 12월 중 공개 될 예정입니다.
  • 다음과 같이 Antelope 소프트웨어 문서 업데이트를 진행하고 있습니다.
    1. CDT 내부의 암호화 확장 기능(crypto extension)을 사용하여 암호화 원시 호스트 기능(Crypto primitive host function)을 활용하는 방법에 대한 문서.
    2. 시스템 컨트랙트 관련 문서 업데이트.
  • ENF 는 2023년 3~4월을 목표로 leap 4.0 으로의 업그레이드를 계획하고 있습니다.
  • EOS Support 에서는 블록체인이 성장함에 따라 용량이 급증하는 blocks.log 파일을 앞으로 어떻게 효과적으로 활용할 수 있을 것인가에 대한 피드백을 받기 위해 설문을 진행하였으며 그 결과는 다음과 같습니다.
    EOSsupport_blockslog_survey.pdf — Google Drive
  • 그 외에도 다음과 같은 의견들이 있었습니다.
    1. Blocks.log 를 분할할 필요는 있지만 EOSIO v2.1 에서 사용했던 방식은 아카이빙 된 블록에 접근하기가 쉽지 않기 때문에 쓸모가 없었다.
    2. 다른 장소, 예를 들어 속도가 느린 디스크 스토리지 같은 곳에 일부 블록을 저장하는 기능이 있으면 괜찮을 것이다.
    3. 예를 들어 이더리움처럼 자동으로 피어를 찾은 다음 BitTorrent 로 부터 히스토리를 다운로드하여 채워넣는 기능과 비슷하게, EOS 에도 노드 인스턴스간에 블록을 공유하는 또다른 방법이 있으면 좋겠다고 BP 들이 답하였다.
    4. API 노드를 운영하는 BP 들의 경우, 블록의 일부만을 가지고 있는 노드 인스턴스가 자신이 가지고 있지 않은 블록 정보에 대한 API 요청을 받았을 때, 다른 노드로부터 그 블록을 가져와서 API 요청에 응답할 수 있는 기능이 있으면 좋겠다고 답했다.
  • 기술적인 논의 끝에 몇 가지 새로운 기능을 ENF 의 개발 백로그(개발해야 하는 기능 및 우선순위 목록)에 추가하였습니다.

Week 1~5 는 소프트웨어 업데이트와 위 설문과 관련된 내용이 회의의 주된 내용이었습니다.

Week 6

ENF는 Antelope 개발 로드맵을 보다 투명하게 해 줄 공개 프로그램 관리 시스템을 시연하였으며, 이를 커뮤니티가 보고 참고하거나 참여할 수 있게 할 것입니다.

Week 7

  • P2P 기능 향상을 위한 기술 토의가 있었습니다. 그리고 Antelope 연합 우선순위 시스템을 시연하였습니다.
  • Antelope 연합은 P2P 피어 디스커버리에 우선순위를 두고 새로 RFP 를 발행하였습니다.
  • 수요일의 정기 기술 미팅 명칭을 EOS Node Operator Round Table 로 변경하였습니다. Leap 업그레이드도 다룰 것이지만 이후 로드맵상의 업그레이드에 영감을 주기 위한 기술적 토론의 장으로도 활용할 것입니다.

Week 8

Week 9

  • 상태 데이터베이스 트리밍(State Database Trimming)에 대한 논의를 진행하였습니다.
  • 현재 상태 데이터베이스는 메모리를 너무 많이 잡아먹고 있으며, 이는 점점 더 커질 것이고 그에 따라 관리하기도 어려워질 것이기 때문에 성능과 메모리 크기 사이에서의 트레이드 오프를 고려해야 하는 이슈가 있습니다.

단기 대책

  • 이 이슈를 연구하기 위하여 Antelope 연합이 RFP 초안을 작성하고 있다.
  • Heap 모드를 사용하면 시작과 셧다운을 빠르게 진행할 수 있다.
  • tmpfs 를 적극적으로 사용하는 방법이 있을까
  • Account query 를 사용하지 않으면(disabled) 메모리를 아낄 수 있다. 노드 운영자 옵션에서 설정 가능하다.
  • Account query 를 디스크에 저장(WAX 에서 약 14M 계정이 4GB 정도를 차지한다. 그 정도의 가치는 없을 것이다.)

장기 대책

  • 스마트 컨트랙트가 메모리 대신 디스크를 사용하도록 장려할 방법이 없을까.
  • 메모리가 아주 크고 CPU도 빠른 하드웨어를 하드웨어 벤더들이 제작해 줄 필요가 있다.

Week 10

Leap 4.0 에서 추가하고자 하는 통계 지표 및 기능들은 다음과 같습니다.

  • 얼마나 자세히 모니터할 것인지 설정할 수 있는 기능.
  • 통계 지표를 수집할 때 노드에 영향을 최소화할 것(다른 스레드로 구동).
  • 로깅하고 있는 모든 내용.
  • Get info 에서 조회 가능한 데이터 (헤드블록, LIB 등등).
  • 노드의 설정내용 ex) 런타임 종류, OC의 사용여부, 콘솔로그 on/off, 블록로그 종류(풀 노드인가, 스냅샷으로 트리밍된 노드인가)
  • 나중에 데이터를 json 으로 리턴하는 또다른 get info 엔드포인트가 추가될 수 있음.

--

--