Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to choose feed producers #6

Open
abitmore opened this issue Oct 30, 2019 · 7 comments
Open

How to choose feed producers #6

abitmore opened this issue Oct 30, 2019 · 7 comments

Comments

@abitmore
Copy link
Member

We need to setup standards for feed producers.
We need to define a workflow about how to choose feed producers and how to pay them.

As proposed in the forum, my initial idea:

  • feed producers deposit some BTS to committee or another account controlled by the community
  • the community define the rules / formulas for feeding price. Feed producers are encouraged to participate in the process
  • the community allows some feed producers to experiment new rules
  • feed producers will get paid according to their performance, will get paid less if not done the job good enough
  • the deposit will be deducted if a feed producer made serious mistakes.

Still need to work out the details.

Please discuss.

@bangzi1001
Copy link
Contributor

feed producers deposit some BTS to committee or another account controlled by the community

Agree. Zero barrier of entry mean no commitment nor responsibility needed but high barrier of entry will discourage new feed producers to join. I suggest the BTS deposit should not more 1 month expected return as feed producer.

the community allows some feed producers to experiment new rules

I suggest either the committee create a new asset on mainnet eg. CNYTEST or just reuse asset eg. ABITS.CNY to allow feed producers demonstrate their price feeding skill. (Testnet not stable recently)

@grctest
Copy link

grctest commented Nov 2, 2019

Why should feed publishers be paid?

How is the deposit deducted if feeds are inaccurate? Would this be manual or automated?

@froooze
Copy link

froooze commented Nov 6, 2019

Why should feed publishers be paid?

Feed publisher is an important service, which trades the collateral and limits debt on blockchain.

@bangzi1001
Copy link
Contributor

Discussion on this topic at dpos.club:
https://dpos.club/t/topic/119/7

@grctest
Copy link

grctest commented Nov 6, 2019

Why should feed publishers be paid?

Feed publisher is an important service, which trades the collateral and limits debt on blockchain.

Price feed publishing has one of the cheapest fees, publishing doesn't cost that much. If the price feed publisher is a witness they are already paid sufficiently to feed.

@abitmore
Copy link
Member Author

abitmore commented Nov 6, 2019

Price feed publishing has one of the cheapest fees, publishing doesn't cost that much.

It's arguable. Cost for feeding prices contains not only network fees, but also man-hours for monitoring and tuning the scripts and even hiring developers, server rents, paid price data source services and etc.

If the price feed publisher is a witness they are already paid sufficiently to feed.

I'd expect that witness pay will be reduced if they're no longer required to publish price feeds. Just my own speculation though.

@shulthz
Copy link

shulthz commented May 9, 2020

我来说一下我的观点与看法:

大前提: 不再将喂价人与见证人分离。

  1. 活跃见证人必须提供理事会锚定资产的喂价;

  2. 前34位的备份见证人也可以提供喂价;

  3. 喂价提供人享受锚定资产区的市场手续费奖励;

  4. 喂价人依然实行准入机制,按照见证人投票排序进入,最大人员为34,有效喂价数现在最小为7.

我的看法是应当有一套决定喂价人的准入踢出投票机制来代替理事会在其中的作用,以实现最大的去中心化。

如果这个投票机制实现起来比较漫长而且繁琐,那暂时只能是:
理事会负责日常的准入退出管理(按照见证人排序);
紧急情况,理事会或者其他人发提案,社区投票处理。
监督依然由社区监督。

这样,

  1. 即使一半多的见证人被社区投票踢出喂价体系而不是见证人体系,也不会影响到喂价安全,因为还有其他的活跃见证人及备份见证人这个喂价人员冗余;

  2. 留出了替换活跃见证人的时间与缓冲,备份见证人有足够的时间调试与准备,替换活跃见证人工作可以循序渐进的进行,而不会因为以前大量活跃见证人被撤票,备份见证人准备不足而影响网络安全;
    也就是喂价将是见证人的考核标准之一。

  3. 喂价提供人享受锚定资产区的市场手续费分成可以激励喂价提供者提供及时而高质量的喂价,同时也能够保持备份见证人有足够的活跃性,增强系统的鲁棒能力。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants