Adds framework for the documentation of analyzed tools

[nabialek-arianelabs]

Adds framework for research documentation of EVM analytic tools:

• creates directories template
• adds boilerplate files: tested smart contracts, execution reports and exceptions
• creates README file

[acuarica]

Hi @nabialek-arianelabs, thanks for sending this. Is there any particular reason to include specific analysis files, maian-analysis and slither-analysis, in this PR? Does it make sense to include these in their respective PRs? This way the other PRs would be self-contained.

[acuarica]

Just went through the README, added a couple of details.

I haven't gone through the rest as per #726 (comment).

[acuarica]

From analyze potential tools it looks like we are evaluating the tools, not the smart contracts.

[arianejasuwienas]

@acuarica This sentence is correct. The focus of these reports is the analysis of the tools.

[acuarica]

Suggested change

	- Issues with compatibility for contracts ported from Ethereum or other networks to the Hedera.
	- Compatibility issues with contracts ported from Ethereum, or other EVM networks, to the Hedera network.

[acuarica]

nit: isn't Kubuntu too specific? Can we say just Ubuntu?

Suggested change

	Tools were tested in the MacOS and Kubuntu Linux environments as well as on Docker containers. Test setup involves:
	Tools were tested in MacOS and Kubuntu Linux environments as well as on Docker containers. Test setup involves:

[acuarica]

Maybe I'm missing something here, but why do we need the relay? Aren't these analysis tools static? If so, I don't see the dependency with the relay.

[arianejasuwienas]

@acuarica Our analysis included investigating the possibility of replacing their APIs with Hedera Json Rpc in MAIAN and Manticore tools.

But I guess you are right - it is not crucial for the final report, so I've removed it.

[acuarica]

nit: By the docs alone looks odd.

[acuarica]

nit: Canonical instead of vanilla?

[acuarica]

Is there a reason to include the generated files? To see the actual report result, might be better to include the analysis in CI and published the results from there.

[acuarica]

Hi @arianejasuwienas, we have discussed with the team the main points of these PRs. From its contents, it is not entirely clear what the purpose of these PRs is. However, from your comments it seems the main goal is to evaluate the suitability of these tools in a Hedera project. If that's the case, could you rewrite the docs to make that explicit?

There is no need to include full report and logs output, at most, some sample report output might be embedded in the docs. All the docs may be placed inside a folder tools/analysis (leaving room for other kind of tools in the future). Instructions and config files, e.g., for docker, on how to run these tools might be included as well.

Without the report and logs output the PRs might be just a few files. If that's the case, it might be easier to merge them into a single PR (like the original one posted in the relay hashgraph/hedera-json-rpc-relay#2439).

The references for Etherscan API keys don't apply for Hedera, those should be removed.

Happy to discuss this further is something is not clear.

team in cc @ebadiere @AlfredoG87 @quiet-node

[arianejasuwienas]

@acuarica

Test reports are a critical component of our research. Removing them entirely from the contexts in which we draw conclusions from performed tests would be challenging.

Perhaps, in such cases, we could maintain these reports in a separate repository and reference them in this specific PR.

Omitting Etherscan API information entirely means we lose essential details: Slither's ability to access resources directly from the blockchain is not compatible with Hashscan. My proposal is to condense this information but still retain it in the report.

[acuarica]

Hey @arianejasuwienas,

Test reports are a critical component of our research. Removing them entirely from the contexts in which we draw conclusions from performed tests would be challenging.

I might be missing something here, but why it would be challenging? If the focus is on the Smart Contracts themselves, I agree, but this is not the case. Some example report might be worth including, but not all of them.

Perhaps, in such cases, we could maintain these reports in a separate repository and reference them in this specific PR.

Sure, that might be a potential solution. However, having these reports in a separate repo begs the question of whether to move the whole evaluation into a separate repo.

Omitting Etherscan API information entirely means we lose essential details: Slither's ability to access resources directly from the blockchain is not compatible with Hashscan. My proposal is to condense this information but still retain it in the report.

One clarification first: Etherscan is both a block explorer and a verification service. Hashscan is only a block explorer. The verification service that we use is based on Sourcify and is provided by a different service.[*]

Here what's important is that slither-read-storage does not support Hedera networks. slither-read-storage seems to only support Etherscan-like services. I don't think the problem comes from eth_getStorageAt, I think the problem comes from not having the source code given the error ERROR:SlitherSolcParsing:crytic-compile returned an empty AST. If you are trying to analyze a contract from etherscan or similar make sure it has source code available.. From the slither-read-storage docs https://github.com/crytic/slither/blob/master/slither/tools/read_storage/README.md

Limitations

• Requires source code.

---

[*] Hashscan could in principle provide a Etherscan-like API given that it has the block information and can act as a facade for the verification service. This might be worth exploring in the future.

[arianejasuwienas]

Replaced with: #740