Standard Doesn’t Always Mean Best:EVM’s Critical Flaws

If alien archeologists studied our society, they would be forgiven for thinking that humans absolutely love spending long amounts of time in tiny spaces, each one tightly packed into a large group and each one looking the same.  After all, the cubical farm is a dominant office space strategy, used by thousands of large corporations globally.  Airlines pack more and more people into big metal tubes that haven’t gotten bigger.  What do you mean, beige isn’t the top favorite color of the human race?

The issue is, just because something is standard or an industry leader doesn’t mean it is the best.  In the case of cubical farms and airlines, the decision is being made by people who are completely biased by profitability vs. overall good, and who are choosing not to calculate elements difficult to measure (worker/passenger wellbeing, loyalty, productivity, etc.).  This isn’t likely going to change, but it’s important for us to take a more critical view of the world around us, and ask ourselves “why” something is being used as the standard.

When it comes to blockchain, Ethereum has long dominated the decentralized world with their EVM architecture.  At the time it was revolutionary, as it took the crypto industry beyond tokens and into the many, many use cases of the blockchain.  Suddenly people could build onto a chain without having to make their own.  We went from not having anything, to having something.  Since that time though, there have been major innovations in the industry.  While Ethereum too is trying to keep up, simply changing the consensus method will not create a suddenly-efficient chain for its many participants.  Further, one of the many benefits of being on any chain are your neighbors.  With bridging still in relative infancy (as seen by the many hacks on bridges this year alone), the bigger an ecosystem in the blockchain world, the better. 

Perhaps this momentum is why we have been willing to ignore some of the critical flaws in the EVM, but if you measure both the direct and indirect results, the EVM does not hold up as a standard for the industry.  There have been a number of other chains being developed to move away from EVM, but many of them are working especially to escape the traffic jams and gas fees of the network.  These issues are valid, but there are four even bigger issues that need to be addressed.  A team of engineers from Radix have spent the last eight years working to fundamentally remove these issues, and believe they have finally cracked the code.  Let’s address each of these four areas and compare the approaches of EVM vs. Radix Engine.

Smart Contract Design

The fundamental piece of any decentralized architecture is the smart contract, which governs the behaviors and rules autonomously.  This was a major breakthrough when first developed, and created a common code for developers to work through.  For EVM, this has created a blueprint and language for others to follow, but in assessing the effectiveness of their smart contract, it is concerning that so many flaws, hacks, exploits, and issues are happening—especially when the platforms are written by some of the industry’s most experienced developers.  If experts are struggling, then what hope do younger, less experienced teams have?  It is easy enough to develop a dApp on EVM, but that does not mean it is safe, secure, or efficient. 

Radix’s approach has been to acknowledge that there are very few, very experienced designers who can successfully program the code needed for EVM.  This can be measured by the number of exploits on EVM, and calls for a different approach.  The team’s insight was seeing that so many of the aspects within blockchain development are around assets.  Much like object-oriented programming, if they can center the paradigm around assets, wouldn’t it make the surrounding code structure easier to code, review, debug, and understand?  Their Scrypto programming language was the result, an asset-oriented language they believe is much easier to learn, understand, debug, and audit—all things that decentralized programming needs desperately right now.

Modularity

In step with the smart contract design, having an architecture that is modular is critical to a bustling, expanding ecosystem.  So far with EVM this growth has come from the sheer “gold rush” fever of crypto, harkening images of hoards flocking to San Francisco with a pickaxe and a dream.  As the market cools, stabilizes, and matures, this fever will subside and only those wanting to build something sustainable and truly value-added will remain.  The issue is that EVM does not promote easy modularity, and so we are stuck once again with very few capable developers spending most of their time essentially re-inventing the wheel before they can even begin coding the value added elements of a platform.  

Radix has taken this issue to heart as well, again noting that 80% of a blockchain platform has similar building blocks.  Tokens, transactions, users, wallets—none of these are new, but they are certainly required.  Why should developers start from scratch when they begin building?  The Radix team developed a way for clean-coded elements of a platform to be easily created and stacked up like using Legos to build a house.

Developer Ecosystem

Now that the developer tools are sorted, it’s critical to create a thriving developer ecosystem.  Again, Ethereum made breakthroughs in setting up an environment where different platforms could build onto a single chain.  However, the incentives for this system were to keep everything close to the vest and keep talent focused on one’s own dApp.  This creates a competitive environment and overall growth, but is limited by the top-to-bottom architecture skills of every single platform.

Radix, like many others, saw this growth throttled by hostile competition.  While an open sharing platform has its own major risks and drawbacks, using basic economics to both reward and encourage openness has significant precedence.  Instead of using code or culture alone, Radix developed the ecosystem whereby developers can place chunks of their code out for the community to use, but are then rewarded with royalties when it is used by someone else.  This is a simple but incredibly effective way to encourage sharing, encourage better and better chunks of code, and as a surprising side benefit, create an entirely new side industry where talented developers build code chunks for royalty use without having to launch an entire dApp themselves.

True Scalability

The last issue, as seen by the current network congestion and plans that can only partially alleviate it, is network/ecosystem scalability.  This has been a challenge for the vast majority of chains, and was one of the most difficult challenges faced by the Radix team as well.  While Ethereum’s improvements will smooth out obvious scalability issues, when the network swells it will not have the ability to efficiently process these transactions. 

Radix made over five attempts before they developed their Cerberus protocol, which as their WP states,

“allows massive parallelization of both simple transactions and complex dApps through specialized form of sharding and a breakthrough ‘braided’ multi-shard consensus mechanism that allows all assets and smart contracts to be freely and atomically composed on a transaction-by-transaction basis.” 

When your network is connected and requires consensus, it takes radical measures to be able to both expand and maintain atomic composability.

Looking Ahead

As the blockchain industry continues its inevitable journey toward mainstream adoption, it will take these moves away from EVM to make it happen.  While it was revolutionary for its time and for what the industry needed, EVM has only taken us so far.  It will take new ideas, designs, and innovations from industry players like Radix and others in order to move the industry to the next level.