EOS Node Operator Round Table (Week 16) — Jan/18

Week 16 — January 18 — Antelope resource model recap, future topics, special-purpose nodes · Issue #113 · EOS-Nation/leap (github.com)

Leap 소프트웨어 현황

• Leap 소프트웨어 3.1, 3.2 의 SHiP(State History Plugin) 에서 발생한 불안정성 문제를 해결할 패치가 곧 공개될 것입니다.
• D.U.N.E(Docker Utility for Node Execution) 의 새 버전이 곧 공개될 예정입니다.

EOS 노드 운영자 테크니컬 라운드 테이블

ENF의 Brian 은 리소스 모델 상태 업데이트를 제공하고 향후 라운드 테이블 미팅 주제에 대한 피드백과 특수 목적 노드에 대하여 보다 구체적으로 논의하기 위한 토론을 진행했습니다.

리소스 모델에 대한 간략한 상태 업데이트

• 아직 아래 나열한 일들을 하기로 정해진 것은 아님.
• 문제점에 대한 토론
• RAM 확장성 제한
• 사용 편의성 문제를 완화
• 서비스 노드에 미치는 영향
• 잠재적으로 범위를 확인
• 실패한 트랜잭션에 대한 청구
• 프록시 계층에서 오프체인 서비스 노드 남용 방지를 사용하도록 설정
• 상태 확장 방법에 대한 전략
• RAM 비용 절감률을 낮추기 위한 방법
• 계정 리소스 사용량에 접근할 수 있는 컨트랙트
• 다음 단계
• 이러한 변경 사항이 ENF, 포멜로 그란츠 수령자, RFP 수상자가 진행하고 있는 다른 어떤 변경 사항과 관련성이 있는지 확인
• 이니셔티브 선택
• 다른 이니셔티브보다 우선 순위를 높게 지정
• 대상 릴리스로 구성
• 기술적 설계
• 작업 분석

향후의 라운드테이블 미팅 주제 브레인스토밍

• Ross: 노드 피어링 해결과제들
  - 피어 로테이션
  - State of Peer 레이턴시 상태.
  - Ross: 첫 번째는 Matthew 의 EOS nation 도구.
  - Daniel: EOS Nation 에는 피어링만 담당하는 풀타임 근무자가 있다.
  - Kevin: 한번에 100블록만 가져오는 기본설정은 좋지 않다.
• Denis: 단일 리소스 모델
  - NET 과 CPU 를 병합할 수 있는 자세한 방법
  - Denis: 체인이 사용 편의성을 해결하기 위해 앵커 및 파워업과 함께 사용한 내용
  - 어떤 네이티브 솔루션을 구현할 수 있을까?
  - BOID 파워업 툴
  - Aaron/Greymass가 WharfKit 를 구현하고 있는 지금이 기회(https://wharfkit.com/)
  - PowerUp이 안되는 가장 흔한 이유는 PowerUp이 필요하기 때문이다.
  - BOID — 가능성있는 “간단한 승리” 솔루션은 엔드포인트에서 트랜잭션을 수신한 다음, Auto Powerup 을 트리거한다.
  - 서버 구현이 가능해지기 전에 새로운 클라이언트 SDK 가 준비될 수도 있다.
• Aaron: 자원 지불자(Resource Payer) 가 eosio 2.1 에는 있었지만 LEAP 에는 없다.
  - 이건 Leap 에 도입해도 좋을 것이다.
  - no-op 액션은 덧붙이지 마라.
  - first-action 이 지불자(payer)인 것을 오버라이드 하는 프로토콜 기능을 사용할 수 있다.
• Aaron: 피어간에 연결을 보장하는 방법
  - peer key 와 같지만 우선순위를 가지는 방식
  - 노드 운영자는 퍼블릭 노드를 돌릴 수 있지만, 비선호 피어(non-preferred peers) 때문에 Full 이 될 수 있다.
• Denis: 컨트랙트 내에서 다른 컨트랙트의 에러를 처리하는 방법
  - 컨트랙트는 서로 상호작용한다.
  - 에러 발생해도 명시적이지 않다.
  - 에러가 발생해도 어느 컨트랙트에서 발생한건지 알 수가 없다.
  - Matt Witherspoon 이 Backtrace 에 대한 아이디어를 가지고 있음

특수 목적 전용 노드

• Aaron: 읽기 전용 nodeos 인스턴스
  - Steem 에는 노드를 시작할 때 설정할 수 있는 flag 가 있어서 노드를 읽기 전용으로 만들 수 있었다.
  - 상태 데이터에 대한 읽기 전용 노드
  - 동기화와 트랜잭션 푸시 방지
  - 읽기 전용 nodeos 인스턴스는 다른 nodeos 인스턴스의 상태 파일을 읽음.
  - Greymass 는 자신만의 상태 파일을 필요로 하는 여러 노드를 돌리는 서버를 운영하고 있다.
  - 이는 노드가 동기화 및 쓰기에 필요한 부하를 줄일 수 있게 한다.
  - 좀 극단적인 대안
  - 상태 그 자체가 다른 솔루션에 스트리밍 될 수 있을까? DFuse 나 The Graph 처럼?
• Matthew: 릴레이 전용 노드는 상태를 가질 필요가 없다.
  - 이건 예전에 논의한 적이 있다.
  - 블록 전파에 효과적일 수 있다.
  - Kevin: 관련된 PR
  - [Propagate block after header validation #590](https://github.com/AntelopeIO/leap/pull/590)
  - [Parallelize Read-only Transaction Execution Design Document #130](https://github.com/eosnetworkfoundation/product/pull/130/files)