ERC20 Permit Component #1140

immrsd · 2024-09-10T11:59:25Z

PR Checklist

Tests
Documentation in a separate PR
Added entry to CHANGELOG.md
Tried the feature on a public network

ericnordelo

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.

CHANGELOG.md

packages/presets/src/erc20_permit.cairo

packages/token/src/erc20/extensions.cairo

packages/token/src/erc20/extensions/erc20_permit/erc20_permit.cairo

andrew-fleming

Looking good, sir! I do agree with Eric with having ERC20Permit as an embeddable impl inside of ERC20Component. This should be a little easier to integrate into a contract. Aside from this, I left a few comments :)

packages/token/src/erc20/extensions/erc20_permit/erc20_permit.cairo

packages/presets/src/erc20_permit.cairo

packages/token/src/tests/mocks/erc20_permit_mocks.cairo

packages/token/src/tests/erc20/test_erc20_permit.cairo

codecov · 2024-09-27T16:25:04Z

Codecov Report

Attention: Patch coverage is 94.44444% with 1 line in your changes missing coverage. Please review.

Project coverage is 89.01%. Comparing base (32a8d2b) to head (72ab63d).

Files with missing lines	Patch %	Lines
packages/token/src/erc20/erc20.cairo	93.33%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1140      +/-   ##
==========================================
+ Coverage   88.87%   89.01%   +0.14%     
==========================================
  Files          57       59       +2     
  Lines        1375     1393      +18     
==========================================
+ Hits         1222     1240      +18     
  Misses        153      153

Files with missing lines	Coverage Δ
packages/testing/src/constants.cairo	`100.00% <100.00%> (ø)`
...kages/token/src/erc20/extensions/erc20_votes.cairo	`95.91% <ø> (+1.80%)`	⬆️
packages/token/src/erc20/snip12_utils/permit.cairo	`100.00% <100.00%> (ø)`
packages/token/src/erc20/snip12_utils/votes.cairo	`100.00% <100.00%> (ø)`
packages/utils/src/cryptography/snip12.cairo	`83.33% <ø> (ø)`
packages/token/src/erc20/erc20.cairo	`95.34% <93.33%> (-0.43%)`	⬇️

... and 1 file with indirect coverage changes

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32a8d2b...72ab63d. Read the comment docs.

andrew-fleming

Nice job on the improvements! This looks almost ready to me. I left a small suggestion and a question

packages/token/src/erc20/erc20.cairo

andrew-fleming · 2024-10-01T03:03:36Z

packages/token/src/erc20/extensions/erc20_permit.cairo

Sooo it seems a little misleading to me to have the impl in the core module and keep the erc20_permit module name under extensions. Do you think erc20_permit_utils would be better?

Actually, that was my initial decision while refactoring. But having two files under extensions erc20_votes and erc20_permit_utils seemed inconsistent and the "utils" suffix felt redundant. I don't have a strong opinion on this matter, I'm okay with both of the names

I agree, it's not great. I'm okay with the current erc20_permit for now. @ericnordelo any strong opinions on this?

For consistency with the recent SNIP-9 addition, I would move the file under erc20 but outside of extensions, and rename it to snip12_utils.cairo, since it only contains snip12 utilities. We should also move the erc20_votes snip12 utilities that are currently in the same file of the component, to that new file outside extensions.

We should probably have only one snip12_utils module per package, meaning that a refactor of SNIP-9 would also be required, but I think is worth doing that to improve/keep organization.

Something like:

token └─── erc20 │ └─── extensions │ │ │ erc20_votes.cairo │ └─── snip12_utils │ │ │ votes.cairo │ │ │ permit.cairo │ │ erc20.cairo │ │ extensions.cairo │ │ interface.cairo │ │ snip12_utils.cairo

Restructured the files accordingly

ericnordelo

Great job with the refactor @immrsd! Left some comments.

packages/token/src/erc20/erc20.cairo

ericnordelo · 2024-10-01T16:39:29Z

packages/token/src/erc20/erc20.cairo

+            spender: ContractAddress,
+            amount: u256,
+            deadline: u64,
+            signature: Array<felt252>


Suggested change

signature: Array<felt252>

signature: Span<felt252>

We should favor Span<felt252> over Array<felt252> since it is significantly cheaper as parameter for external functions (related to Serde and compiler internal implementation of the type).

We should favor Span over Array, but in this case we need Array (to make the is_valid_signature call to the owner's account, which expects a signature as Array<felt252>)

Similar to the implementation in SRC9, we should receive the Span, and call into when calling is_valid_signature, since we only keep that Array for BC with the interface Id, but we should not continue adding more Array when not needed. It would be nice if you could profile the calls using Span and into vs and Array to compare steps.

packages/token/src/erc20/erc20.cairo

ericnordelo · 2024-10-01T17:41:20Z

packages/token/src/erc20/extensions/erc20_permit.cairo

For consistency with the recent SNIP-9 addition, I would move the file under erc20 but outside of extensions, and rename it to snip12_utils.cairo, since it only contains snip12 utilities. We should also move the erc20_votes snip12 utilities that are currently in the same file of the component, to that new file outside extensions.

We should probably have only one snip12_utils module per package, meaning that a refactor of SNIP-9 would also be required, but I think is worth doing that to improve/keep organization.

Something like:

token └─── erc20 │ └─── extensions │ │ │ erc20_votes.cairo │ └─── snip12_utils │ │ │ votes.cairo │ │ │ permit.cairo │ │ erc20.cairo │ │ extensions.cairo │ │ interface.cairo │ │ snip12_utils.cairo

ericnordelo · 2024-10-01T17:43:25Z

packages/token/src/erc20/interface.cairo

+        spender: ContractAddress,
+        amount: u256,
+        deadline: u64,
+        signature: Array<felt252>


Suggested change

signature: Array<felt252>

signature: Span<felt252>

We have to require a signature in the format of an array

See #1140 (comment)

ericnordelo · 2024-10-01T17:45:02Z

packages/token/src/erc20/interface.cairo

@@ -107,3 +121,43 @@ pub trait ERC20VotesABI<TState> {
        ref self: TState, sender: ContractAddress, recipient: ContractAddress, amount: u256
    ) -> bool;
 }
+
+#[starknet::interface]
+pub trait ERC20PermitABI<TState> {


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.

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

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.

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

packages/token/src/tests/erc20/test_erc20_permit.cairo

ericnordelo · 2024-10-01T17:50:48Z

packages/token/src/tests/erc20/test_erc20_permit.cairo

+    utils::declare_and_deploy_at(
+        "DualCaseAccountMock", data.owner, array![data.key_pair.public_key]
+    );


Is something preventing us from using COMPONENT_STATE instead of deploying and dispatchers? Note that using COMPONENT_STATE should speed up running the tests.

There's nothing preventing us from following the approach with CONTRACT_STATE, but there's also no strong reason why this approach is better. I reckon that having a contract deployed and interacting with it through dispatcher feels closer to the real-world usage scenario and also prevents from using any internal functions that
are not supposed and even can't be called externally

Either way tests run pretty fast. That's compilation that takes most time. With that said, I think it's fine to keep interacting with the contract under test through a dispatcher. What do you think?

I had the same thoughts when we started following this logic, we already had a discussion about it and decided to test components as separate modules, since they are not deployed contracts, but modules to extend those. Declaring and deploying in tests take time and adds up while we continue adding more tests. I'm not against reopening the discussion about it, but for now, since we should always favor consistency, let's refactor into using COMPONENT_STATE as we've been doing when possible for component tests.

immrsd added 6 commits September 5, 2024 16:43

Add ERC20Permit component

a055099

Add ERC20Permit preset

cfa836a

Add ERC20Pemit mock and update visibility modifiers

9973d9a

Add tests for ERC20Permit component

23ba5da

Add tests for ERC20Permit preset

87f1859

Run linter

67c3fc7

immrsd requested review from ggonzalez94, ericnordelo and andrew-fleming September 10, 2024 11:59

immrsd self-assigned this Sep 10, 2024

ericnordelo reviewed Sep 11, 2024

View reviewed changes

andrew-fleming reviewed Sep 12, 2024

View reviewed changes

immrsd added 6 commits September 25, 2024 13:02

Merge main

a499394

Remove ERC20Permit preset

4bfbe36

Add ERC20Permit as a trait of ERC20Component

09fb2d2

Remove ERC20Permit component, restructure files

950205e

Update tests

1c2fc82

Fix test error messages

5702d0c

immrsd requested review from ericnordelo and andrew-fleming September 25, 2024 16:47

Make slight changes to functions doc

3e48a9a

andrew-fleming reviewed Oct 1, 2024

View reviewed changes

ericnordelo reviewed Oct 1, 2024

View reviewed changes

immrsd added 6 commits October 5, 2024 20:04

Address review issues

8fbbe48

Update changelog

26ce488

Restructure files

acad601

Support fixes in tests

2cef6d1

Merge main

4d23651

Fix changelog

72ab63d

immrsd requested review from ericnordelo and andrew-fleming October 6, 2024 06:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ERC20 Permit Component #1140

ERC20 Permit Component #1140

immrsd commented Sep 10, 2024

ericnordelo left a comment

andrew-fleming left a comment

codecov bot commented Sep 27, 2024 •

edited

Loading

andrew-fleming left a comment

andrew-fleming Oct 1, 2024

immrsd Oct 1, 2024

andrew-fleming Oct 1, 2024

ericnordelo Oct 1, 2024

immrsd Oct 5, 2024

ericnordelo left a comment

ericnordelo Oct 1, 2024

immrsd Oct 5, 2024

ericnordelo Oct 7, 2024

ericnordelo Oct 1, 2024

ericnordelo Oct 1, 2024

immrsd Oct 5, 2024

ericnordelo Oct 7, 2024

ericnordelo Oct 1, 2024

immrsd Oct 5, 2024

ericnordelo Oct 7, 2024 •

edited

Loading

andrew-fleming Oct 7, 2024

ericnordelo Oct 1, 2024

immrsd Oct 5, 2024 •

edited

Loading

ericnordelo Oct 7, 2024

ERC20 Permit Component #1140

Are you sure you want to change the base?

ERC20 Permit Component #1140

Conversation

immrsd commented Sep 10, 2024

PR Checklist

ericnordelo left a comment

Choose a reason for hiding this comment

andrew-fleming left a comment

Choose a reason for hiding this comment

codecov bot commented Sep 27, 2024 • edited Loading

Codecov Report

andrew-fleming left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericnordelo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericnordelo Oct 7, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

immrsd Oct 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Sep 27, 2024 •

edited

Loading

ericnordelo Oct 7, 2024 •

edited

Loading

immrsd Oct 5, 2024 •

edited

Loading