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: add basic policy middleware #400

Merged
merged 2 commits into from Aug 23, 2021

Conversation

mattsse
Copy link
Collaborator

@mattsse mattsse commented Aug 23, 2021

Motivation

Support a way to enforce certain rules for transactions

Solution

Add a new PolicyMiddleware type which wrapps a middleware and includes an instance of the new Policy trait, which is a single function to ensure a transaction is in compliance with this policy.

Further work

common use cases could be to look up the receiver in a database and check if its address is whitelisted. Not sure yet what the most flexible implementation would be since a DB adapter is database specific and also how to check for a whitelisted address may be database model specific. So we could abstract basic use cases via some kind of PolicyBackend trait or smth which implements common functions for checking is_whitelist(&self, recv: Address) and also for checking the calldata maybe. We could also add a default persistent implementation of that (postgres for example) and a HashSet based one and feature gate this.

Copy link
Owner

@gakonst gakonst left a comment

Choose a reason for hiding this comment

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

Excellent, this interface looks great: async fn ensure_can_send(&self, tx: TypedTransaction) -> Result<TypedTransaction, Self::Error>;

I don't think we really need the policy backend trait given the quirks of each individual platform.

Let's start with a simple in-memory one, and we can start adding databases afterwards. Agreed that if they introduce new deps (eg tokio-postgres) they should be feature gated.

Simple functionalities:

  • to can only be in whitelist
  • from can only be in whitelist
  • value cannot be over X ETH
  • data can only follow certain patterns (e.g. match first 8 bytes to limit function selector, or even more granularly limited the args based on the function selector)

@gakonst gakonst merged commit 8587b3e into gakonst:master Aug 23, 2021
meetmangukiya pushed a commit to meetmangukiya/ethers-rs that referenced this pull request Mar 21, 2022
Co-authored-by: Tim Lancina <tlancina@users.noreply.github.com>
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.

None yet

2 participants