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

update executeUserOp implementation #149

Merged
merged 1 commit into from
Aug 23, 2024

Conversation

livingrockrises
Copy link
Contributor

@livingrockrises livingrockrises commented Aug 21, 2024

msgSender field that the hook sees
one major upside of delegatecalling to the account only is that existing hooks will be more easily compatible

eg a spending limit hook will decode the execute calldata and check for the function signature but in the case of using the executeUserOp func on nexus the calldata could be address(erc20), transfer(...) in which case hooks also need to be able to decode this
If you instead have the account delegatecall to eg execute, then the hook can just decode normally

there are no real downsides to delegatecall here

Copy link

🤖 Slither Analysis Report 🔎

Slither report

# Slither report

THIS CHECKLIST IS NOT COMPLETE. Use --show-ignored-findings to show all the results.
Summary

constable-states

Impact: Optimization
🔴 Confidence: High

base/RegistryAdapter.sol#L10

factory/RegistryFactory.sol#L39

_This comment was automatically generated by the GitHub Actions workflow._

Copy link

Changes to gas cost

Generated at commit: 69b47bd8f24c5255ab2ff0a0a03bbac1599c6d01, compared to commit: 847828b5ba32696d19e543ee36e5fe20ef290650

🧾 Summary (5% most significant diffs)

Contract Method Avg (+/-) %

Full diff report 👇
Contract Deployment Cost (+/-) Method Min (+/-) % Avg (+/-) % Median (+/-) % Max (+/-) % # Calls (+/-)
Nexus 5,641,328 (-12,762)

Copy link
Collaborator

@filmakarov filmakarov left a comment

Choose a reason for hiding this comment

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

Agree, that delegatecall'ing here is better

Copy link
Collaborator

@filmakarov filmakarov left a comment

Choose a reason for hiding this comment

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

I have a question. Can we limit execute to be onlyEntryPoint , not onlyEntryPointOrSelf ?
Now when executeUserOp doesn't call execute , I think we can do it
This will make execute safer for using with SmartSessions

@livingrockrises
Copy link
Contributor Author

I have a question. Can we limit execute to be onlyEntryPoint , not onlyEntryPointOrSelf ? Now when executeUserOp doesn't call execute , I think we can do it This will make execute safer for using with SmartSessions

executeUserOp can now delegate call to self with any calldata actually

btw these below methods are also onlyEntryPointOrSelf

  1. installModule
  2. uninstallModule
  3. setRegistry
  4. upgradeToAndCall
  5. _authorizeUpgrade
  6. withdrawDepositTo

@livingrockrises livingrockrises merged commit 54de428 into m_dev_cantina Aug 23, 2024
6 of 8 checks passed
@livingrockrises livingrockrises deleted the feat/update-execute-userop branch August 23, 2024 13:22
@filmakarov
Copy link
Collaborator

executeUserOp can now delegate call to self with any calldata actually

yep, which is good.
I mean, since it can delegatecall now, can we make execute to be onlyEntryPoint ?
It will make execute->execute impossible. so the flow is more deterministic.
otherwise it will be possible to trick user to create some execute->execute permission and bypass some limits with sessions

so I suggest execute to be onlyEntryPoint

@livingrockrises
Copy link
Contributor Author

what do you mean by making execute-> execute impossible? and need for that

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