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, … |
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?
I want to make a clarification on the following line:
EXECUTION COSTS ~ 0.001 $, regardless dApp complexity
because this sentence is potentially misleading if quoted without context, since this comparison table as been largely used by the community as a source for info-graphics and tweets.
Since the time I made this comparison overview between AVM and EVM, the AVM evolved a lot, especially adding a new capability such as Inner Transactions, that could potentially turn the aforementioned sentence into misinformation.
Like I tried to clarify here and more recently here, the intent of that sentence is highlighting that the AVM applies the same flat fee model even for the execution of Smart Contracts calls, and not just for regular transactions. This of course doesn’t mean that users have infinite computational resources at a fixed cost, but means that knowing that your application consumes 3 or 5 transactions users can predict exactly that the cost of execution will be 3 or 5 times a flat fees. Since the introduction of Inner Transactions this clarification is even more necessary, because is now very easy for Algorand Smart Contract to issue several transactions in the same execution call.
This being said, I apologise if this statement has been confusing for the community somehow, and I truly hope this clarification can avoid spreading of misinformation on a wonderful and powerful technology as the AVM.
Cosimo,