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

delegation design #1045

Merged
merged 6 commits into from Nov 14, 2018

Conversation

Projects
None yet
4 participants
@imeckler
Contributor

imeckler commented Oct 26, 2018

Check out the RFC rfcs/0006-delegation-of-stake.md which proposes several designs for delegation, of which I endorse design 3.

@cmr

This comment has been minimized.

Contributor

cmr commented Oct 27, 2018

This design seems fine. I'm pretty sure 1-level delegation will be sufficient for our purposes.

(with the intention, whether it be enforced on chain or not, that they would receive some of the block reward as in a mining pool).

Do you have ideas on how to enforce that in the SNARK? I think you'd need to examine at least every account delegating to a block winner to ensure they all get paid. I don't think it's a major problem for this to happen off-chain, just wondering if you had something in mind.

@es92

This comment has been minimized.

Contributor

es92 commented Oct 27, 2018

A few other considerations

  • Paying delegators

    • We can't really get away with not tracking everyone who's delegating to us (we should pay them). Fortunately this is pretty easy, just a map reduce over a ledger, then a fold over any more recent transactions
    • Securing this inside the snark seems extremely expensive. Doing it outside seems fine though. Assuming the staking pool coordinator pays back at a reasonable rate (maybe once a day), losing everyones trust seems pretty costly (we should do an analysis of stealing one set of rewards vs taking in a cut of rewards over many sets to compare)
  • VRF evaluation worthwhileness

    • I made a script that given some parameters returns the minimum account balance where its worthwhile to evaluate a vrf, In summary, its in the range of a few cents to a few dollars
    • I haven't done the full analysis on this, but its already pretty costly to pay a delegator because of fees. I bet the break even point for paying someone is way higher than the break even point for running their vrf
  • I also want to add something on goals, there's a couple

    • We want as much value staked as possible, we want the percent being staked to be as high as possible to make it as difficult as possible for an adversary
    • Another neat thing we can do - someone with a big balance can delegate to another account controlled by them, then put their private key in cold storage while still staking
@bkase

This comment has been minimized.

Contributor

bkase commented Nov 4, 2018

@imeckler Could you update the RFC with Evan's considerations and that we're now leaning towards Option 1 (assuming this is still true, makes sense to me though)

@bkase

bkase approved these changes Nov 6, 2018

This seems good to me, we can update it with more details as we go about the implementation

bkase added some commits Nov 6, 2018

@imeckler imeckler merged commit f6fb967 into master Nov 14, 2018

8 checks passed

ci/circleci: build Your tests passed on CircleCI!
Details
ci/circleci: build_public Your tests passed on CircleCI!
Details
ci/circleci: build_withsnark Your tests passed on CircleCI!
Details
ci/circleci: test-all_sig_integration_tests Your tests passed on CircleCI!
Details
ci/circleci: test-all_stake_integration_tests Your tests passed on CircleCI!
Details
ci/circleci: test-unit-test Your tests passed on CircleCI!
Details
ci/circleci: test-withsnark Your tests passed on CircleCI!
Details
ci/circleci: tracetool Your tests passed on CircleCI!
Details

@imeckler imeckler deleted the rfc/delegation branch Nov 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment