What is the status of supporting EVM target or can we restore the part generate LLVM bitcode for Ewasm?

[taquangtrung]

Hi,

I am using Solang to generate LLVM bitcode for the Ewasm target to do static analysis of Solidity smart contracts.

Unfortunately, I just notice that the implementation for Ewasm target was removed last month in this commit: https://github.com/hyperledger/solang/commit/f59edd6d262129c30c77ce27a97b4c7ed19dec61

I tried to generate LLVM bitcode for other targets Substrate and Solana, but the output bitcode files are different from the output bitcode files generated for Ewasm previously.

May I ask what is the status of generating LLVM bitcode to EVM target?

If this may take too long, can we restore the part generating to Ewasm?

Removing Ewasm seems like a hug breaking change for Solang :(

[seanyoung]

Ethereum is not implementing ewasm. ewasm is not happening - it's dead in the water.

So our plan is to repurpose the ewasm for evm. However, there is no codegen yet - there is no evm target for llvm.

What plans do you have for ewasm?

[taquangtrung]

I don't use Ewasm but just want to compile Solidity to the LLVM IR format that is closest to EVM bytecode (e.g., calling built-in functions of EVM directly). I'm implementing an LLVM-based bug-finding tool for Solidity and want the LLVM IR to follow closely the feature of EVM.

Previously, Solang can generate such IR via the ewasm target. But now it's gone.

How much work do you expect to generate the evm target?

Maybe I can help to implement some part of this feature?

[seanyoung]

This is a valid use case. I'm not sure how we should best support this use case, let me get back to you on that.

Out of interest, could you tell us more about the tool you are building @taquangtrung ?

[taquangtrung]

Yes, it will be great if Solang can continue to support EVM target.

It will definitely be useful for many use cases, like the one mentioned in this issue https://github.com/hyperledger/solang/issues/1005: to check the correctness of Solang compared to Solc.

For me, I'm developing a static analysis and bug-finding tool based on abstract interpretation for smart contracts. This is an R&D project at the Singapore Blockchain Innovation Programme and the National University of Singapore (https://sbip.sg/).

We target 2 blockchains: Ethereum (Solidity smart contracts) and Solana (Rust, C++ smart contracts). In the backend analyzer, all analyses are performed at LLVM bitcode level. And we are using Solang to compile Solidity to LLVM IR. Currently, I'm using Solang from the older commit https://github.com/hyperledger/solang/commit/a553c0b0085fddef282e746f8a0650468648b408, which still allows compiling to Ewasm.

Are you planning to develop the EVM target soon?

I'm happy to help with some development tasks for this feature.

[xermicus]

And we are using Solang to compile Solidity to LLVM IR

Please keep in mind that solang is not attempting to be a 1:1 clone of solc in regards of low level details. This is mainly due to the differences in the backend; the ewasm target implementation could yield somewhat different IR code than what would be generated by solc (setting up system/runtime/API or whatever external calls for example). How-ever, depending on your type of research it might not be an issue. Additionally, since solang is a much younger project than solc itself, there might still be rare bugs in the semantic analysis we do. This could lead to incorrect conclusions as to what exactly is the root cause of a discovered bug, as in you'd have to prove that any discovered bug stems from a some error in solidity code, regardless of the compiler in use (this is situation is what I'd like to improve with solving #1005).

based on abstract interpretation for smart contracts ... Ethereum (Solidity smart contracts) and Solana (Rust, C++ smart contracts).

Out of curiosity, how does this "abstract interpretation" look like? Many things work entirely different in solidity (or are not even possible) than in smart contracts written in other languages and vice-versa. I see the use case of generating LLVM IR of Solidity contracts for the purpose of fuzzing or symbolic execution. But I can't see yet what research questions you are trying to answer by comparing the LLVM backend code of other compilers to the one generated by solang?

Are you planning to develop the EVM target soon?

I'm happy to help with some development tasks for this feature.

With all of the above being said, I'm very excited about your use case! Implementing an EVM target won't be a mundane task and any form of contribution will be highly appreciated. At the moment we are still busy completing things for the other targets. We'd like to have a mentor-ship planned for this task in early 2023. But naturally, if you want to take matters mostly into your own hands, please feel free to start with it any time (unfortunately I won't be able to spare much time for this task, at least in short terms). What aspects of the implementation would you feel especially comfortable taking over and how much time could you spend on it?

Also we don't have concrete plans on how to best implement such an EVM backend. Code generation could for example be implemented directly in solang or by implementing a LLVM backend for EVM first. Such a project exists already, unfortunately it looks it was abandoned years ago.

[dvc94ch]

Ethereum is not implementing ewasm. ewasm is not happening - it's dead in the water.

That is a shame. I've been trying to find some more information on the status of ewasm. Do you have a reference to some discussion about this and the decision to abandon ewasm?

[seanyoung]

I don't have anything concrete to point you to apart from the absence of ewasm from all ethereum roadmaps/plans.