ERC20 Permit Component #1140
ERC20 Permit Component #1140
Conversation
There was a problem hiding this comment.
Hey Alejandro, the implementation is looking good, but I think we should refactor this into an extra embeddable implementation in the ERC20Component, instead of an extra component, since this would reduce the boilerplate in the final contract, and a component without storage members and events can be just an extra module.
packages/token/src/erc20/extensions/erc20_permit/erc20_permit.cairo
Outdated
Show resolved
Hide resolved
packages/token/src/erc20/extensions/erc20_permit/erc20_permit.cairo
Outdated
Show resolved
Hide resolved
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1140 +/- ##
==========================================
+ Coverage 91.53% 91.76% +0.22%
==========================================
Files 46 48 +2
Lines 1182 1202 +20
==========================================
+ Hits 1082 1103 +21
+ Misses 100 99 -1
... and 2 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
| @@ -107,3 +121,43 @@ pub trait ERC20VotesABI<TState> { | |||
| ref self: TState, sender: ContractAddress, recipient: ContractAddress, amount: u256 | |||
| ) -> bool; | |||
| } | |||
|
|
|||
| #[starknet::interface] | |||
| pub trait ERC20PermitABI<TState> { | |||
There was a problem hiding this comment.
We don't need to add an extra ABI trait, but include the new implementations in the ERC20ABI trait, even if the user can choose not to use some implementations, the ABI should contain the full ABI of the component.
There was a problem hiding this comment.
ERC20Mixin actually implements ERC20ABI. If we include permit fns into ERC20ABI, we'll have to require ERC20Permit to be implemented for ERC20Mixin to become available. I don't think we should do that and that ERC20Permit is the feature that should be expected to be ON by default
This way it makes total sense to have an additional interface named ERC20PermitABI, so it can be used for the cases when the trait is included and implemented
There was a problem hiding this comment.
ERC20Mixin (and other mixins) implement the ABI of the component by coincidence, but not by definition. Mixin and ABIs are different things, even when they sometimes match.
A Mixin is a set of implementations that are commonly used together (as mentioned here) whose objective is to avoid verbosity. A component ABI trait, on the other hand, is intended as a single dispatcher for the component full interface, even if it doesn't have to be implemented all-together, as explained in this recently added note:
We didn't follow this principle in Ownable and OwnableTwoStep because the same function (transfer ownership) with the same interface has different implementations that can be problematic if they are used thinking the other one is in place, so we favoured clarity over the rule. In this case, the permit implementation doesn't have a problematic intersection and can be added to the ABI as intended.
In this case, we can use #[generate_trait] for the mixin instead of implementing from the ABI trait, and we should add permit to the existing ABI.
Note that adding a different ABI per feature would create a lot of repetition in the interface file if the component grows bigger in features.
TLDR: Mixin shouldn't be necessarily pegged to component ABIs, since they are not defined as the same thing.
cc @andrew-fleming that may correct me if I recall something the wrong way from when we worked on this definitions.
There was a problem hiding this comment.
This sounds accurate to me. Looking at the docs now, I do think we can improve our definition of ABI traits. We mention that they're useful for preset contracts; however, this isn't necessarily true anymore. We have a preset interfaces dir now and the ABI doesn't include the interface for upgrades. Further clarity and purpose would be helpful IMO
TLDR: Mixin shouldn't be necessarily pegged to component ABIs, since they are not defined as the same thing.
Maybe it's worth using #[generate_trait] for all the mixins to establish a better differentiation
There was a problem hiding this comment.
#[generate_trait] won't help here since the embeddable trait has to implement a starknet interface. I decoupled mixin impl from ABI and added a IERC20Mixin interface
There was a problem hiding this comment.
Looking good @immrsd ! I left a small suggestion, but besides that I think it is ready to go.
@ggonzalez94 this will generate some conflicts with the Votes PR.
| fn test_invalid_sig_bad_deadline() { | ||
| let data = TEST_DATA(); | ||
| let (owner, spender, amount, deadline) = (data.owner, data.spender, data.amount, data.deadline); | ||
| let mut state = setup(data); |
There was a problem hiding this comment.
This is an example of a test that doesn't use the DualCaseAccountMock, should we decouple the setup_account logic from the setup one?
There was a problem hiding this comment.
This particular test case doesn't require the account mock to be deployed. At the same time, I don't think we should decouple it, since this way we'll lose consistency over the test cases and we'll have to introduce an additional setup function that will be used in this only place
Implements ERC20Permit extension
PR Checklist