Skip to content
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

feat: revert to previous 1271 implementation #55

Merged
merged 3 commits into from
Apr 22, 2024

Conversation

jaypaik
Copy link
Collaborator

@jaypaik jaypaik commented Apr 19, 2024

Given that there are some issues to address for the 1271 flow (context: https://x.com/howydev/status/1780353754333634738), reverting back to the previous version's implementation of this until we reach consensus on a good approach.

Choosing to keep the SignatureType prefix which improves gas estimation.

@jaypaik jaypaik requested a review from a team April 19, 2024 00:12
/// @dev bytes4(keccak256("isValidSignature(bytes32,bytes)"))
bytes4 internal constant _1271_MAGIC_VALUE_SUCCESS = 0x1626ba7e;
bytes4 internal constant _1271_MAGIC_VALUE_FAILURE = 0xffffffff;
bytes32 internal constant _MESSAGE_TYPEHASH = keccak256("LightAccountMessage(bytes message)");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(No change needed) Do you know what the rationale was for the field being a bytes instead of a bytes32? I might have something a little hazy here, but I believe this field is always containing the hash that's being asked to be signed, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the review!

I was thinking I might want to change that too, but left it as is. This is also what MultiOwnerPlugin has.

I believe the original reason was because that's what Safe does. I'm happy to change it if it won't cause SDK headaches.

Cc @howydev

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation. I think it's fine to stick to what Safe does, I was just curious.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, we inherited that conversion of bytes32 digest -> encoded into bytes -> hashed back to a bytes32 from Safe. It added a little overhead that's probably unnecessary, but I think the SDK already accounts for this. 100% should address this in the next iteration though

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, thanks guys

@jaypaik jaypaik merged commit 0a94800 into develop Apr 22, 2024
2 checks passed
@jaypaik jaypaik deleted the 04-18-feat_revert_to_previous_1271_implementation branch April 22, 2024 01:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants