Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 PoC #504
Delegation PoC #504
Changes from 26 commits
24c72c6
12f8664
717fd66
319af42
8ec0bbd
76e3277
4ea1ff0
abf330e
c290bca
040b9d0
49abda9
f93b3eb
a27e9db
5d8526f
de44d59
9c9db92
070be82
07a215f
89da916
305e475
f751b30
ea1e56b
b6706d7
54f3f7b
31113ad
94d4c1f
036bfa6
7d80231
221e588
66ba792
9571e51
38ba93a
b34d2e5
6b82cbf
bdef782
1f1238b
215f981
ba108a2
e0a8f70
68c9eaa
d63a131
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did we want to offer delegation by default? Thought it was going to be an extension
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally speaking, I prefer to make features optional rather than add complexity to the inheritance graph by adding extensions to support those features. Inheritance is best used as an abstraction tool to reduce shared code or provide polymorphism.
Regardless, for now I'm going to keep this as part of the PoSValidatorManager for the PoC, and we can revisit inheritance later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think more so thinking to allow Subnets to choose validator manager contract's that don't include delegation by default, and they can simply deploy the contract without delegation logic, as opposed to for reducing shared code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that validators should have the option to not support delegation. There are many ways to do that, such as providing that toggle as a constructor argument, or leaving it up to the individual validator to specify when they register. I'll enumerate those options and defer to a followup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good I'm good with deferring. Likely would push back as a constructor argument for turn on/off, since that increases contract bytecode and deployment costs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to worry about deployment costs, as these contracts will be deployed by subnet owners
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it may make more sense here to create a notion of a
delegationID
(similar tovalidationID
) to key these maps on.Theoretically, an address should be able to delegate to the same validation ID multiple times. This would also have the benefit of having a single ID to refer to a delegation rather than a composite key, and hopefully reduce the number of state lookups since there won't be nested mappings.
The
delegationID
could be a hash of the (validationID
,nonce
), where the nonce is the nonce used in theSetSubnetValidatorWeight
message that added the delegator.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This idea came up previously. I agree that using a unique delegation ID rather than the address is the way to go, but going to defer that to a followup.
Using the nonce rather than a timestamp (as originally suggested in the linked conversation) seems like the way to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i like the (validationID, nonce) hash combo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will delegators be able to update their delegations and add more stake to the same validationID? Seems like a use case we should support
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's defer this to a followup.
I think the safest way to this would be to come up with a unique delegation ID that takes into account the validatorID, the delegator address, and maybe the starting timestamp for uniquenes. Then add a separate delegation owner field, rather than using the delegator address for that purpose. That would also be more general, since the address that adds the delegation would not need to be the same address that claims rewards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if this would make a big UX difference for delegators. Couldn't they just start a separate delegation with the additional stake in most cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree with Cam here. Let's use the timestamp for uniqueness for the ID, that way one address can make multiple delegations, which prevents us from ever having to change the details of a delegation. We should have a way for any given address to access all of their delegations though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current case they could but would have to use a separate address given this check. I do like the idea of the delegation owner field being tracked separately from the delegator address
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good with deferring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're going to need a new field to track the original weight of the validator. It'll be needed if the validator ends validation period to calculate their rewards, because right now we'd have to use the total weight with the delegations included.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds right to me, but we can defer to when handling delegation exit rewards
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went ahead and added that here, so that it doesn't fall through the cracks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would advocate to only add it in when needed because future changes might not need it or want to implement differently, for example, whether
startTime
is only needed for PoS, or using a separate mechanism as a whole. Not a big deal though now that's already added.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we were to store the latest acked nonce for a given validationID, we could have a much cheaper function to complete a delegator registration if the nonce of the registration is less than or equal to the latest acked nonce, which would save on the warp message verification. Feel free to defer this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Going to defer this to a followup, since it is an optimization. Definitely think we should support this though.
Check notice
Code scanning / Slither
Reentrancy vulnerabilities Low
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should be checking uptime, giving out rewards, and returning stake in here I think?
For uptime, I think anyone should be able to provide an uptime proof for a validator. Since we track the seconds of uptime, a proof can be provided basically at any point, and if the highest reported
uptimeSeconds
is at least 80% of the time from the validation period starting and the MIN(validation end, current time), then we can disburse rewards.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to defer uptime/rewards handling since I think there are still some open design questions here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I implemented uptime handling here: #520
Happy to merge that into this branch and include it in this PR if you prefer.