Nine Chronicle's network participation compensation policy change for PoS

[riemannulus]

Context & Problem

현재 저희가 PoS 전환 시 타겟으로 삼고 있는 구현체는 cosmos sdk 입니다. 대부분의 경우 구현을 변경하는 것엔 엔지니어링적 논의만 필요하지, 기존 나인 크로니클의 정책을 변경해야 할 일은 없었습니다.

하지만 Cosmos SDK의 네트워크 참여로 인한 블록 보상 정책은 블록을 캐는 사람에게 고정된 에셋을 분배하는 것이 아닌, 인플레이션율에 따라 보상을 계산하여 주는 형태입니다.
예를 들어, 검증자 A가 제안한 블록에 대한 보상은 A가 모은 증거와 트랜잭션에 의해 결정된 basis 보상이 10 NCG라면, 여기에 max token cap 및 여러 요소에 따라 결정되는 인플레이션율을(여기서는 0.5%라고 하겠습니다.) 곱해 10.5 NCG를 보상으로 받게 되는 형태입니다.

이런 Cosmos의 인플레이션율 계산 기반의 토큰 분배 방식은 필드에서 충분히 전투적 테스트가 완료된 방식이라고 판명됩니다만, 이를 그대로 가져오기에는 기존에 제안된 네트워크 참여에 대한 NCG 분배 제안서에 위배됩니다.

Propose

따라서 저희에게는 두 가지 안이 있습니다.

1. NCG 분배 제안서를 변경하고 Cosmos 식의 인플레이션율 기반 분배 방식을 채택한다.

• Pros
  • 충분히 테스트 된 Cosmos 의 구현을 거의 그대로 사용 가능하다.
• Cons
  • NCG 분배 제안서를 변경하는 것은 많은 이해가 얽혀 있는 일이다.

2. 현재 동작하는 NCG 분배 제안서랑 최대한 비슷한 형태의 기존 구현체를 찾아 구현한다.

• Pros
  • NCG 분배 제안서를 수정하지 않아도 된다.
• Cons
  • Cosmos만큼 충분히 테스트 되지 않은 제안이라 불안 요소를 가지고 있고, 알기 힘든 컨센서스 공격이 들어올 수 있다.

토큰 분배 방식이 변하게 되는 만큼, 많은 의견 부탁드립니다.

Reference

• F1 Fee Distribution (https://drops.dagstuhl.de/opus/volltexte/2020/11974/pdf/OASIcs-Tokenomics-2019-10.pdf)

[riemannulus]

from @jckdotim

총 발행량을 10억개를 넘지 않도록 세팅할 수 있다면 그 안에서의 토크노믹스 업데이트는 괜찮을 것 같습니다.

위와 같은 의견이 있고, libplanet은 토크노믹스에 있어 max cap 등의 지정을 직접적으로 하지 않고 애플리케이션의 구현에 일임하기 때문에 1번 안을 진행한 후 lib9c에서 토큰 캡을 지정하는 형태로 구현을 진행하도록 하면 되겠습니다.

[riemannulus]

cc. @OnedgeLee

[longfin]

https://docs.google.com/spreadsheets/d/1w3fytHo9hIPbr7SVtIQNRbKLxHH94eoaQeSfAMPtLRM/edit#gid=0

9c 제너시스에 기입된 초기 배분과 블록 보상 변동 추이입니다. cc @riemannulus @OnedgeLee @jckdotim