Refactor the code to be more object oriented, pythonic

[newgnart]

Why working on researching on Kodiak which was deployed on Berachain I eventually came here which is a great scanner but doesn't supported Berachain and I spotted some points that can be improved:

• make the etherscan.py aka block explorer an object (with default base_url, but can change in Berachain for example)
• make it as a python project that can be installed by pip
• is it a good idea to also have option to scan local contracts, or it's not necessary?

Let me know what you guys think. I'm down to work on all those refactoring.

[yvesbou]

Hey @gnart33 thanks for raising this issue

1. sure
2. do you mean the permission scanner becoming a pip supported library? -> sure feel free
3. Yes, that's a good option, but needs a bit a longer explanation 👇

We use slither to objectify the contracts and this makes functions and their properties queryable. Slither works with contract addresses for common chains (Bera is too new) and but also local contracts. To make local contracts work there needs to be some changes, it is kind of on our roadmap, but we are busy with other milestones.

fetch_contract_metadata calls this API endpoint by etherscan https://docs.etherscan.io/etherscan-v2/api-endpoints/contracts#get-contract-source-code-for-verified-contract-source-codes

Slither does too, when you just gives addresses to it, line 175 (main.py). Slither stores the files in a distinct manner. We would need to extract this logic and put it before instantiating slither, such that slither can directly work with the local file system. This way we control the available chains.

And ofc it's just important that the script is aware of the whole inheritance and libraries the contract is using.

[yvesbou]

additional info: the way slither interacts with etherscan is the following found here:
venv/lib/python/site-packages/critic_compile/platform/etherscan.py

[newgnart]

Gotcha, will open a PR soon