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

[Improvement] Context data for plugin execution functions #7

Open
adam-alchemy opened this issue Dec 1, 2023 · 1 comment
Open

Comments

@adam-alchemy
Copy link

  • There are 3 system-wide variables for an EVM call: the sender, the value, and the call data. Validation functions and hooks have access to all of these, but execution functions only have access to calldata. Some execution functions could benefit or be written more concisely if they have access to this information.
  • There are 2 techniques we could use to implement this:
    • Change execution functions to not be defined directly on the plugin, but through a similar “routing function” like the validation/hooks in IPlugin
      • This has the downside of making the plugins no longer “implement” the functions themselves, and they become harder to write.
    • Pass the sender and the value in as “secret parameters” by appending to the end of calldata.
      • This works with ABI-encoded functions, but breaks with some other types of function calls that just capture the entire calldata. It also requires odd integration code from the plugins to access this data.
@huaweigu
Copy link

huaweigu commented Apr 25, 2024

Some thoughts on option 1:
I think this could be an optional feature rather than a mandatory one. Developers who wish to leverage features associated with the modular plugin can choose to implement the interface that facilitates this functionality. However, if developers are content with the existing methods, it should be perfectly acceptable for them not to adopt the new interface methods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants