-
Notifications
You must be signed in to change notification settings - Fork 375
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
Allow a specified address to disable/enable rewards distribution #1828
Conversation
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.
return [ | ||
config.registry.predeployedProxyAddress, | ||
network.from, |
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.
network.from
is validator 0. I think this should be a different key because it's validator key is quite sensitive.
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.
Any ideas what else this could be? validator-0 is fairly convenient as that has been the address we use in our tooling to manage test networks (throughout celotool, I believe that's the address that has faucet balances), but agree that we might need to think differently about baklava.
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.
It could be any key, including one generated on the fly. You could generate it from the same mnemonic and might create a new AccountType.ADMIN
https://github.com/celo-org/celo-monorepo/blob/master/packages/celotool/src/lib/generate_utils.ts#L23
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.
What do we currently set other things to? I.e. the approver, reserve spender, etc.? I agree validator 0 isn't the most robust choice, but I believe it's currently the standard choice
Codecov Report
@@ Coverage Diff @@
## master #1828 +/- ##
=========================================
- Coverage 74.43% 74.2% -0.23%
=========================================
Files 281 278 -3
Lines 7822 7653 -169
Branches 974 672 -302
=========================================
- Hits 5822 5679 -143
+ Misses 1883 1857 -26
Partials 117 117
Continue to review full report at Codecov.
|
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.
It would be good to make the key management change I mentioned, but overall LGTM. Thanks for addressing my comments!
@@ -217,6 +217,65 @@ describe('governance tests', () => { | |||
assertAlmostEqual(currentBalance.minus(previousBalance), expected) | |||
} | |||
|
|||
const waitForBlock = async (blockNumber: number) => { |
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.
Thanks for cleaning this up!
@@ -372,6 +379,10 @@ contract EpochRewards is Ownable, Initializable, UsingPrecompiles, UsingRegistry | |||
* @return The per validator epoch payment and the total rewards to voters. | |||
*/ | |||
function calculateTargetEpochPaymentAndRewards() external view returns (uint256, uint256) { | |||
if (frozen) { |
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.
nit: This shouldn't strictly be necessary, since if one epoch rewards action fails we won't execute any of them.
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.
Yep. @nategraf recommended this change for robustness.
One nice thing about how this is implemented is that after Baklava we can just delete the baklava/
directory and then remove any code that the compiler complains about.
return [ | ||
config.registry.predeployedProxyAddress, | ||
network.from, |
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.
What do we currently set other things to? I.e. the approver, reserve spender, etc.? I agree validator 0 isn't the most robust choice, but I believe it's currently the standard choice
* master: (27 commits) Experience Brand Kit 1.0 (#1948) Adjust reference to the rewards app (#2065) [Wallet] Compatibility with exchange rate in string format (#2060) Fix Typo in CI config (#2056) Fix additional attestations instructions (#2057) Allow a specified address to disable/enable rewards distribution (#1828) Aaronmgdr/leaderboard patch (#2055) Move attestation service instructions to main page (#2051) Point To Updated Join Celo Video (#2052) Fix minor issue withe the ordering of instructions changes to docs related to discovery (#2025) [Docs] Fix typos in Running a Validator docs (#2045) Add node flag to celocli to set the target node for a single command (#2020) Fix broken links and spruce up CLI docs for accounts command (#2027) Prevent clipping of arrow component (#2036) Allocates an initial balance to the attestation bot (#2019) gold and dollar flags are required for faucet script (#1943) Clean seed words text area when returns from empty wallet view (#1904) Update validator script (#2026) Docs: PoS, metadata, gateway fee plus cleanup (#2022) ...
* master: (208 commits) Fix potential hard timeouts (#2072) Add checkzero,blockscout,mulit-address support to faucet. Fix broken envType checks (#2068) README added mission (#1972) Add dev-utils README (#2081) Add validator:status command to check if a validator signer is online and producing blocks (#1906) Experience Brand Kit 1.0 (#1948) Adjust reference to the rewards app (#2065) [Wallet] Compatibility with exchange rate in string format (#2060) Fix Typo in CI config (#2056) Fix additional attestations instructions (#2057) Allow a specified address to disable/enable rewards distribution (#1828) Aaronmgdr/leaderboard patch (#2055) Move attestation service instructions to main page (#2051) Point To Updated Join Celo Video (#2052) Fix minor issue withe the ordering of instructions changes to docs related to discovery (#2025) [Docs] Fix typos in Running a Validator docs (#2045) Add node flag to celocli to set the target node for a single command (#2020) Fix broken links and spruce up CLI docs for accounts command (#2027) Prevent clipping of arrow component (#2036) ... # Conflicts: # packages/web/src/layout/BookLayout.tsx # packages/web/src/lib.dom.d.ts
Description
For Baklava, we want the organizer to be able to turn off rewards distribution. This PR uses the previously introduced
Freezable
interface to makeupdateTargetVotingYield
freezable. Celo-blockchain will, upon reverting on calling the frozen function, produce an epoch block without distributed rewards.Tested
Unit and e2e tests.
Other changes
Reorganized helper functions in e2e governance test.
Related issues
Backwards compatibility
Not backwards compatible, smart contract has new storage layout.