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

FIP 004: Multi validators #4

Open
bejavu opened this issue Jan 2, 2020 · 2 comments
Open

FIP 004: Multi validators #4

bejavu opened this issue Jan 2, 2020 · 2 comments

Comments

@bejavu
Copy link
Contributor

bejavu commented Jan 2, 2020

FIP 004: Multi validators

Motivation:

In the current state, a validator needs exactly 3M tokens to be a validator. If he has less, he needs to find delegators to delegate to him, without him proving himself first as an ongoing reliable validator. If he has 3M tokens he doesn’t need (or even can add) more delegators, since there is a limit, and even if there was no limit, it will only dilute his share.

Suggestion

First, we’re lowering the minimum staking requirement to 100K (see FIP-3)
Second, we are making the following changes:
Any validator can create its own “validator account” in the consensus contract.
The validator needs to set a list of different addresses that he controls or simply a xpubkey if it is possible.
The validator can stake using this contract by sending FUSE tokens to this contract. Delegators can send their delegations using this contract as their validator also.
Now every 100K FUSE tokens that a validator have staked is a Ticket.
A validator can have several tickets.
The consensus contract will fill exactly 100 validators (randomly) for the next cycle using the validators’ tickets.
The more tickets one has, the more slots he will get in the 100 length validator set.
The only problem is that the validator set can’t have duplicate addresses. So the consensus will take several addresses from the address set (or derive it from the xpubkey) of the validator contract.
The validator needs to be able to upload several validators as the amount of addresses he has that entered the validator set.

Example and Illustrations to come

@fileflume
Copy link

  1. Assuming that each address/wallet must have it's own copy of the blockchain within the fuse node. Rather than multiple wallets running off the same copy of the blockchain.
  2. Multiple nodes on 1 piece of hardware is a liability, as more nodes will be affected by a hardware failure. Maybe consider limiting number of nodes allowed on 1 piece of hardware
  3. "Validator account" controls things like fee% for all instances?

@fileflume
Copy link

It is possible to run multiple nodes at the moment. How is FIP 004 intending to benefit the Fuse network or validators, except for the "validator account" idea?

One could just run multiple validators individually without the need for the 'validator account' - what is it's benefit?

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

2 participants