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

[WIP] Staking checkpointing #415

Closed
wants to merge 7 commits into from
Closed

[WIP] Staking checkpointing #415

wants to merge 7 commits into from

Conversation

izqui
Copy link
Contributor

@izqui izqui commented Aug 6, 2018

Implements a Staking sub-app that checkpoints a stake holder's balance on every stake/unstake action, conforming to the optional history methods of ERC900.

This is a required primitive for implementing stake-based voting with any ERC20 (w/o Minime) in a governance model that doesn't require locking tokens. An interesting combination would be a Voting app that requires a stake-lock in order to perform certain actions (create a proposal or vote favorably).

I'm currently thinking about whether we should move locking functionality off the main Staking contract in a similar fashion, as it would make it easier for us to implement different types of locking without adding exponential complexity, like it is currently happening with overlocking in #409 (cc @bingen)

To do:

  • Test StakingHistory with existing staking.js tests (✅ all passing)
  • Test history-specific functionality
  • (?) MiniMe interface wrapping for automatic compatibility with current MiniMe-compatible voting apps.

@izqui izqui self-assigned this Aug 6, 2018
@izqui izqui requested a review from bingen August 6, 2018 20:11
@coveralls
Copy link

coveralls commented Aug 6, 2018

Coverage Status

Coverage remained the same at 94.91% when pulling 2d72cdf on staking-checkpointing into b8604b1 on staking.

Copy link
Contributor

@bingen bingen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left some minor questions, but overall looks good to me.

uint256 constant MAX_UINT192 = uint256(uint192(-1));
uint256 constant MAX_UINT64 = uint256(uint64(-1));

function add128(History storage self, uint192 value, uint64 time) internal {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does 128 in function name here mean? Shouldn't it be 192? Same below.

@@ -14,7 +14,6 @@ contract Staking is ERCStaking, AragonApp {
uint64 constant public MAX_UINT64 = uint64(-1);

struct Account {
uint256 amount;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can get rid of the struct now, as it only has one field.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason for moving amount out of the struct, btw?

@@ -0,0 +1,90 @@
pragma solidity 0.4.18;

library Checkpointing {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the point of making this a Library? Is it going to be used outside of StakingHistory?

while (high > low) {
uint256 mid = (high + low + 1) / 2; // average, ceil round

if (time >= self.history[mid].time) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would split this condition so if (time == self.history[mid].time) return self.history[mid].value;

@bingen
Copy link
Contributor

bingen commented Dec 2, 2018

Closed in favor of https://github.com/aragon/staking/

@bingen bingen closed this Dec 2, 2018
@sohkai sohkai deleted the staking-checkpointing branch December 2, 2018 15:05
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

Successfully merging this pull request may close these issues.

3 participants