EVM and Ethereum API compatibility

Hi guys,

please discuss: do you want that solidity smart contracts run on aeternity blockchain?

This was planned at the beginning (as also seen in early docs/specs) but got dropped by the core devs. Would be great of someone of the core devs could explain why it got dropped as the AEVM is quite similar to the EVM but never made it to become completely EVM compatible.

From my perspective it will be a huge adoption win if aeternity blockchain can also run all the existing solidity smart contracts. Another question is, if it is not already to late to aim for EVM compatibility as there are so many well-funded EVM compatible chains already out there like AVA, Polka, Polygon, …

1 Like

Yes! I hope fate will be compatible with solidity smart contracts。

I think it will be very powerful if it can be compatible with solidity and can run sophia and solidity safely and efficiently at the same time

At the same time, it will attract more developers

This is a question worthy of discussion
It wasn’t Symbian that beat Nokia. It was Android
In the short term, EVM compatibility is a good thing, as many ETH applications can be migrated to AE
There are many EVM compatible public chains, such as BNB, OKT, CFX, etc., so what are the advantages of AE compatibility with EVM?
So I think it would be better to fully support Sophia in terms of tutorials, development tools, samples, etc. It’s important to keep Sophia as simple to developers as Solidity and AeStudio as easy to use as Solodity
So, I don’t recommend supporting EVM in a situation where the core developers are nervous. I suggest focusing on Sophia, whom we are so proud of


I support Baixin’s idea. We shouldn’t be shadowing ETH. The limited time should be spent perfecting Sophia. If we are good enough, everyone will know how to choose

The core technical team is required to assess the development workload and security。If evm-compatible; it is very developer-friendly.If ae is good enough; fate also becomes mainstream

Another problem is that if EVM is selected, the development will basically not use Sophia, which means giving up Sophia, so consider carefully
Why don’t our put all our energy into improving Sophia’s ecology, or we’ll be, like, trying to do everything and not doing anything right
Take advantage of our advantages! Defeat the EVM and ETH

This is an interesting topic - there was an initial effort to keep AEVM and EVM compatible (they are up to some point in a distant past) - but we realised two things:

  1. AEVM/EVM wasn’t the most efficient design of a VM, especially considering that Aeternity had several things (Oracles, Names, State channels, etc) that simply does not exist in EVM.
  2. In Solidity there would be no way to make use of these Aeternity specific mechanisms. So a solidity contract would miss out on possible optimizations.

With these two realisations we wanted to make something better - hence Sophia and FATE. That in itself doesn’t rule out also having AEVM; but maintaining and updating two separate VMs would be a huge undertaking. Also, EVM and FATE are sufficiently different that trying to get cross-VM calls working would be really, really, difficult.


I think if this compatibility can be achieved without consuming more resources, it definitely needs to be done. After all, there are too many benefits. Now EVM is the mainstream and it is difficult to change in the short term. This can bring ecology and vitality to AE, which is what AE needs most now.
However, if this is a big project, it might as well just give up. After all, we have been waiting for so long, and we don’t care if we keep waiting. If our smart contract is better, then what we need to do is to keep improving it, and there is always a chance to be discovered.

1 Like

Aevm has surpassed EVM. We should continue to optimize aevm, make it easy for more people to enjoy AVEM, and improve examples and documents.

1 Like

Sophia of AE is FATE

If this is a big project, you should really think about it, and if sophia is really good enough, then I don’t think it is necessary to be compatible with Evm. I think we should stick to ourselves, although there is indeed very little ecology on aeternity now, but As long as aeternity’s technology is good enough, safe and efficient enough, I believe that there will always be an outbreak of aeternity ecology.

AEVM is the EVM. Sophia currently operates in her FATE

Fully compatible with solidity requires a large Labour overhead, which requires careful assessment.

At the same time run EVM and FATE, you can let Solidity developers do not need to re-learn Sophia.

If you want to let the Eth project migrate to AE is unlikely.

Choosing EVM is not because Solidity is simple, but there are more speculative.

The ETH excellent project we have seen is survived in a huge ecology.

If I am a project investor, I will not consider the cost of Eth or AE. I need to consider who can give me more profits.

Just make a Transpiler for Solidity to Sophia ( an online SPA would be fine or inbuilt sdk command that detects pragma or @compiler difference to begin with, etc. ).

“Just” is a strong word I think… Solidity and Sophia aren’t exactly similar languages. And it would need a lot of maintenance staying in synch with both Solidity and Sophia.


You’re so cool

What if you do not even bother helping with cross-VM calls. Allow contract developers to just make other EVM contracts that speak to EVM contracts. So, porting over, they will not need to worry about this cross compatibility. They can always choose to upgrade (refactor etc…) to FATE at a later time.

Perhaps, the new users can come over and make up for the difficulty.

Another possibility… make a transpiler? So, EVM contracts are converted to FATE compatible contracts. This seems doable because the functions of EVM are all a subset of FATE. i.e. FATE can do everything EVM can do, and more… correct?


Thank you for all of your opinions guys!

What do you guys think about WASM or eWASM? Should aeternity 2.0 have WASM instead or additionally to the FATE VM?

Anyone thoughts on porting of Sophia to (ae)WASM?