What was the rationale around not being EVM-Compatible?

Hey guys,

I’m currently doing some research on blockchains that are EVM-Compatible and I was trying to understand why Algorand chose the option of not being EVM-Compatible or including the Solidity language within the AVM?

I would’ve thought that the benefits would exponentially outweigh the costs by being able to bite into Ethereum’s developer base.

Hi, @orageux101,

The reason was speed: 1000 tps, which will be (hopefully) raised to 42000 tps by the end of year.

P.S. Yes, Solidity would be great, but see Reach, which supports both Algorand and Ethereum.

So, by utilising Solidity (or EVM), it would make the potential speed of Algorand lower?

Reach is a common language between both chains, but my thinking was that the majority of Ethereum dev’s use Solidity. So by incorporating Solidity, you can get a bunch of dApps automatically ported over as well as new Devs.

Hi @orageux101,

the AVM and the EVM are execution environments with very different design and performance. The root causes of such a difference are to be found in several design choices and go back up to the consensus layers on which they operate.

As per today is it impossible for EVM-Compatible environments, that work with PoW, to achieve the same performance the AVM reaches on Algorand’s Layer 1 through the PPoS. While their programmability is just a matter of language, what really differenciates the AVM from the EVM is their core design, given that several compilers could be built on top their respective OPCODEs.

I will drop here just an high level comparison between their (very) different performances that results from their (very) different designs.

AVM EVM
TURING COMPLETENESS YES YES
EXECUTION SPEED ~ 4.5 sec, regardless dApp complexity > 20 sec, depending on dApp complexity
ENERGY EFFICIENCY ~ 0.000008 [kWh/txn], all final > 120 [kWh/txn], not all final
EXECUTION COSTS ~ 0.001 $, regardless dApp complexity ~ 20 $, depends on dApp complexity
INTEROPERABILITY native interoperability with ASA, AT, MultiSig, RekeyTo… user defined solutions and interfaces
SMART CONTRACT FINALITY instant ~ 6 blocks
MATHEMATICAL PRECISION 512 bits 256 bits
PROGRAMMABILITY TEAL, PyTeal, Reach, … Solidity, Viper, Reach, …
3 Likes

Hi Cusma, I once held a small amount of ALGO but took my profits at 2x and my fear was that Ethereum has a massive developer pool and customer base that required eating into for another smart contract platform to compete well.

That’s why I though EVM Compatiblity was essential to help shift these devs and users.

Could AVM not have included Solidity which is the most used language on Ethereum to enable this shift to continue?

Honestly, that’s my last question that stops me from holding again.

Also, I really appreciate your well laid out response!

Algorand and Ethereum have different communities and usecase focus. ALGO in my opinion will never reach the ETH highs. I exited ethereum mainnet, soon after shelling out $30 gas fees for a $100 worth of DeFi transaction. I therefore hope ALGO will never be expensive as ETH.

Thankfully, “to the moon” crypto enthusiasts have not been able to pull a SHIBA INU on ALGO yet!
I Hope the pump & dump speculators focus on other coins, and not freeze the Algorand usecases.

Could the EVM be ported to run on Teal emulator when we have AVM 1.0? In which case would it be performant?