design: initial node on staking,slashing and delegation #44
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was
linked to
issues
Nov 28, 2024
Maddiaa0
reviewed
Dec 1, 2024
| - The list MUST have no gaps to avoid issues with sampling | ||
| - The list MAY contain duplicate `proposer` | ||
| - MUST support adding a new operator to the list, given that they pass some permissionless anti-sybil mechanism | ||
| - MUST support punishing an operator in the set if the misbehave |
There was a problem hiding this comment.
Suggested change
| - MUST support punishing an operator in the set if the misbehave | |
| - MUST support punishing an operator in the set if they misbehave |
Maddiaa0
reviewed
Dec 1, 2024
| The `status` indicate whether the operator is currently `VALIDATING`, `LIVING` or `EXITING`: | ||
|
|
||
| - `VALIDATING` meaning that it is currently active, | ||
| - `LIVING` being that it is not participating in block production but also not exiting the system currently. It is possible to land in this state if a slash cause the validator to fall below the `MINIMUM_STAKE`. |
There was a problem hiding this comment.
Sure, we can do that 🤷
Maddiaa0
reviewed
Dec 1, 2024
| The `SLASHER` can then be implemented as a variant of the `Governance.sol` contract, that skips the wider vote and allow direct execution of the payload if the validators agree. In this manner, the node software itself can be responsible for detecting misbehaviour and submitting slashing proposals, giving us a lot of flexibility as it is mainly off-chain code. | ||
|
|
||
| > [!info] Top-ups | ||
| > We are not supporting "topping up" the account, since it introduce a few additional code paths that we simple are not interested in for this minimal setup. |
There was a problem hiding this comment.
Suggested change
| > We are not supporting "topping up" the account, since it introduce a few additional code paths that we simple are not interested in for this minimal setup. | |
| > We are not supporting "topping up" the account, since it introduce a few additional code paths that we simply are not interested in for this minimal setup. |
Maddiaa0
reviewed
Dec 1, 2024
|
|
||
| Joining and exiting is done directly on the contract, likely using a frontend or CLI but connected to a cold-storage wallet. These actions are seldom and deal with value so it is important to keep it safe. | ||
|
|
||
| As mentioned, the voting on slashing is to be done by the node itself by "slashing-modules". Essentially a small pieces of code that the node is running that will identify misbehaviour and submit or vote on slashing proposal. Votes are collected in the same manner as the `GovernanceProposer` used for governance proposals, with the caveat that if it is "to be proposed" it will go to the slasher where it becomes executable - it does not need to pass a normal governance vote. |
There was a problem hiding this comment.
Suggested change
| As mentioned, the voting on slashing is to be done by the node itself by "slashing-modules". Essentially a small pieces of code that the node is running that will identify misbehaviour and submit or vote on slashing proposal. Votes are collected in the same manner as the `GovernanceProposer` used for governance proposals, with the caveat that if it is "to be proposed" it will go to the slasher where it becomes executable - it does not need to pass a normal governance vote. | |
| As mentioned, the voting on slashing is to be done by the node itself by "slashing-modules". Essentially a small pieces of code that the node is running that will identify misbehaviour and submit or vote on slashing proposal. Votes are collected in the same manner as the `GovernanceProposer` is used for governance proposals, with the caveat that if it is "to be proposed" it will go to the slasher where it becomes executable - it does not need to pass a normal governance vote. |
Maddiaa0
reviewed
Dec 1, 2024
| // Living -> Not participating as validator, but have funds in setup, | ||
| // hit if slashes and going below the minimum | ||
| // Exiting -> In the process of exiting the system | ||
| enum ApeStatus { NONE, VALIDATING, LIVING, EXITING } |
Maddiaa0
reviewed
Dec 1, 2024
| struct OperatorInfo { | ||
| uint256 stake; | ||
| address withdrawer; | ||
| address proposer; |
aminsammara
reviewed
Dec 2, 2024
| - `LIVING` being that it is not participating in block production but also not exiting the system currently. It is possible to land in this state if a slash cause the validator to fall below the `MINIMUM_STAKE`. | ||
| - `EXITING` the operator is currently waiting to exit or yet to claim the funds | ||
|
|
||
| The `withdrawer` is a separate actor, specified per operator that is able to initialise a removal of the operator from the set - without the help of the `proposer` or `attester`. The `withdrawer` can initiate a withdrawal of the `stake` to some `recipient`, moving the status from `VALIDATING|LIVING` to `EXITING`, removing the operator from the set and start the delay. After the delay, the funds can be relayed to the specified `recipient`. This ensure that it is possible to keep the "account in control" in cold store or be a contract itself - lending itself well to supporting LST's |
There was a problem hiding this comment.
Can withdrawer be a contract?
There was a problem hiding this comment.
I see it addressed below
| constructor(address _slasher, ERC20 _stakingAsset, uint256 _minimumStake) { | ||
| SLASHER = _slasher; | ||
| STAKING_ASSET = _stakingAsset; | ||
| MINIMUM_STAKE = _minimumStake; |
There was a problem hiding this comment.
I think previously we discussed having MINIMUM_STAKE specified by the Rollup instance instead of directly on the staking contract. Any thoughts on why this changed?
| require(_args.amount >= MINIMUM_STAKE, "insufficient stake"); | ||
| require(info[_args.attester].status == ApeStatus.NONE, "already registered"); | ||
| // If BLS, need to check posession of private key to avoid attacks. | ||
| require(attesters.add(_args.attester), "already in set"); |
There was a problem hiding this comment.
Is entering the attester set expected to be immediate? Or is this supposed to be handled by the rollup via use of snapshots etc.
There was a problem hiding this comment.
Currently it is already immediate, so it was just kept that way. It is essentially unrelated to the staking itself.
| The `SLASHER` can then be implemented as a variant of the `Governance.sol` contract, that skips the wider vote and allow direct execution of the payload if the validators agree. In this manner, the node software itself can be responsible for detecting misbehaviour and submitting slashing proposals, giving us a lot of flexibility as it is mainly off-chain code. | ||
|
|
||
| > [!info] Top-ups | ||
| > We are not supporting "topping up" the account, since it introduce a few additional code paths that we simple are not interested in for this minimal setup. |
There was a problem hiding this comment.
For validators that want to compound earnings, they must fire up another validator? Like Ethereum currently?
There was a problem hiding this comment.
In our setup there is 0 earnings benefit from increasing the balance of a validator. So ye, run multiple validators.
just-mitch
approved these changes
Dec 2, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Providing a simple design for staking/slashing/delegation.