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(protocol): restrict max gas paying prover #15200

Merged
merged 5 commits into from
Nov 14, 2023

Conversation

dantaik
Copy link
Contributor

@dantaik dantaik commented Nov 13, 2023

No description provided.

Copy link

vercel bot commented Nov 13, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
bridge-ui-v2-a5 ✅ Ready (Inspect) Visit Preview Nov 14, 2023 6:35am
1 Ignored Deployment
Name Status Preview Updated (UTC)
bridge-ui-v2-internal ⬜️ Ignored (Inspect) Visit Preview Nov 14, 2023 6:35am

Comment on lines +31 to +33
// Max gas paying the prover. This should be large enough to prevent the
// worst cases, usually block proposer shall be aware the risks and only
// choose provers that cannot consume too much gas when receiving Ether.
Copy link
Contributor

Choose a reason for hiding this comment

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

Easy for provers to give the proposer an address that is an EOA and then deploy a smart contract to that address that consumes a lot of gas!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, but provers are most likely entities that win their businesses over time by behaving well, some metrics are important for proposer when to consider which provers to use.

Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't they just pick the prover that offers the lowest fee? Anything that is more trust based seems like a downside for the system to work as well and efficient as possible. Any trust based system would also be more centralizing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants