[Flow EVM] Add test cases for restricted EOA functionality

[m-Peter]

• Refactor the EOA restriction functionality
• Add E2E tests to verify the correctness of EOA restriction
• Remove reclaimFundsFromAttackerEOAs function from EVM contract code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov-commenter]

Codecov Report

❌ Patch coverage is 53.84615% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
fvm/evm/emulator/emulator.go	20.00%	2 Missing and 2 partials ⚠️
utils/unittest/execution_state.go	0.00%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[janezpodhostnik]

Are we keeping this feature or is it temporary?
If we are keeping it, we probably want to change some wording in the errors...

[janezpodhostnik]

I would make the restrictedEOAs a map[ChainId]gethCommon.Address, so that their definition is cleaner and we can easily tell which are for mainnet/testnet/etc.

[m-Peter]

Well, I don't think that we actually want to distinguish between networks. If someone had a malicious activity on Testnet, then we certainly don't want their EOA to also interact with Mainnet too. The opposite is also true.

Keep in mind that wallets such as MetaMask, will use the same address between networks, as EOAs are controller by a private key only.

[m-Peter]

Are we keeping this feature or is it temporary? If we are keeping it, we probably want to change some wording in the errors...

@janezpodhostnik Yes, these EOAs will be permanently restricted from accessing Flow EVM. But the error was actually written by comms team. What do you have in mind as an error message?

[janezpodhostnik]

We might need this feature in the future which means the error message maybe shouldn't mention a specific attack:

"this account has been restricted by the Community Governance Council in connection to a protocol exploit, please reach out to security@flowfoundation.com for inquiries or information related to the attack"

->

"this account has been restricted by the Community Governance Council, please reach out to security@flowfoundation.com for inquiries",

[m-Peter]

We might need this feature in the future which means the error message maybe shouldn't mention a specific attack:

"this account has been restricted by the Community Governance Council in connection to a protocol exploit, please reach out to security@flowfoundation.com for inquiries or information related to the attack"

->

"this account has been restricted by the Community Governance Council, please reach out to security@flowfoundation.com for inquiries",

Good point, updated in 0972247 .

[janezpodhostnik]

suggestion: restrictedEOAs is a variable. we could add the test EOA during the test so its not listed here.

[m-Peter]

Good point indeed 👍 Updated in 03e3c7e .