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

RIP-7614: Expose call stack to contracts #10

Merged
merged 4 commits into from
Jan 13, 2025

Conversation

canercidam
Copy link
Contributor

@canercidam canercidam commented Feb 7, 2024

@canercidam canercidam changed the title RIP: Expose call stack to contracts RIP-7614: Expose call stack to contracts Feb 8, 2024
@miohtama
Copy link

miohtama commented Feb 8, 2024

MIM degenbox exploiter worked around smart contract detectors by running the payload directly in the init code (I read this - did not verify myself).

As far as I understand to detect the exploits, the call stack is unwinded and addresses are check against the on-chain blacklist. To make sure that any detectors have enough time to flag malicious smart contracts, would it also make sense to store the contract age (deploy block number) accessible in the smart contract state? It might not be work for this proposal, but as far I understand, it would be quite easy to pass detectors by just deploying the exploit smart contract in the same block as the exploit is run. By having the on-chain call stack detector knowing about the smart contract age, this could be delayed enough, so that on-chain blacklists have enough time to update.

@canercidam
Copy link
Contributor Author

@miohtama Great observations! We have discussed that point a few times before with the authors and the early reviewers of this proposal. We agree that a complementary solution should exist. It looks like this can arrive either in the form of a whitelist check or a contract age check and a blacklist check combination. However, we are considering this problem outside of this proposal. We think that the call stack visibility has a fundamental role in enabling transparent on-chain threat prevention mechanisms, regardless of how the complementary checks could be made.

Copy link
Collaborator

@nconsigny nconsigny left a comment

Choose a reason for hiding this comment

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

LGTM

@nconsigny nconsigny merged commit d8aa0bd into ethereum:master Jan 13, 2025
1 check passed
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.

6 participants