-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
Use Trace208 in Votes to support ERC6372 clocks #4539
Changes from 6 commits
06b4189
48fba73
15ca017
74b8d26
d5ab954
b2cd627
bd9595d
2d93da5
bc335f5
7927100
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
'openzeppelin-solidity': major | ||
--- | ||
|
||
`Votes`: Use Trace208 for checkpoints. This enables EIP-6372 clock support for keys but reduces the max supported voting power to uint208. |
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -9,7 +9,7 @@ import {Checkpoints} from "../../../utils/structs/Checkpoints.sol"; | |||||
|
||||||
/** | ||||||
* @dev Extension of ERC20 to support Compound-like voting and delegation. This version is more generic than Compound's, | ||||||
* and supports token supply up to 2^224^ - 1, while COMP is limited to 2^96^ - 1. | ||||||
* and supports token supply up to 2^208^ - 1, while COMP is limited to 2^96^ - 1. | ||||||
* | ||||||
* NOTE: This contract does not provide interface compatibility with Compound's COMP token. | ||||||
* | ||||||
|
@@ -27,10 +27,10 @@ abstract contract ERC20Votes is ERC20, Votes { | |||||
error ERC20ExceededSafeSupply(uint256 increasedSupply, uint256 cap); | ||||||
|
||||||
/** | ||||||
* @dev Maximum token supply. Defaults to `type(uint224).max` (2^224^ - 1). | ||||||
* @dev Maximum token supply. Defaults to `type(uint208).max` (2^208^ - 1). | ||||||
*/ | ||||||
function _maxSupply() internal view virtual returns (uint224) { | ||||||
return type(uint224).max; | ||||||
function _maxSupply() internal view virtual returns (uint256) { | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why change this to
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm honestly not sure what it implies/change to use uint208 vs uint256 here (note that it's internal) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if multiple modules implement that function with different values (votes limit to 208, but other modules would limit to 224, 192 or 128 for some other reason) how would we resolve that ? If the return types are different it's a mess. If they are both uint256 there may be some hope There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not a concrete problem we have currently so I would go with the option that is safer. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If that issue happens during the 5.x cycle, would we be able to change it without a major change ? I don't think overriding this with a bigger function is something anyone would realistically do. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also the only place we use it, we do an implicit upcast to uint256 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If something like this happens in a minor release I think we would just add an internal function with a name other than There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you feel strongly about this I can accept it. The risk if >uint208 is returned is simply that some transfers might revert but it's a recoverable situation. |
||||||
return type(uint208).max; | ||||||
} | ||||||
|
||||||
/** | ||||||
|
@@ -70,7 +70,7 @@ abstract contract ERC20Votes is ERC20, Votes { | |||||
/** | ||||||
* @dev Get the `pos`-th checkpoint for `account`. | ||||||
*/ | ||||||
function checkpoints(address account, uint32 pos) public view virtual returns (Checkpoints.Checkpoint224 memory) { | ||||||
function checkpoints(address account, uint32 pos) public view virtual returns (Checkpoints.Checkpoint208 memory) { | ||||||
return _checkpoints(account, pos); | ||||||
} | ||||||
} |
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.
Why memory?
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.
The merge with
master
wasn't done correctly. Thanks for raising.