Welcome to Just The Metrics

Read time: 5 minutes

Hey there, Just The Metrics fam! 😄,

Some small favor upfront: It would mean the world if you took a second and be our Newsletter Testimonial. ✨

We’ll share all Testimonials on our Website and Twitter because your unique perspective and experiences with Just The Metrics could be a game-changer for others considering joining our community!

Our book “A 3 Step Assessment Framework of Layer 1 Blockchains” went live on Book.io and we are amazed by all your feedback and support! 💙

Thank you so much! If you are curious, check it out here 👇

Okay, now let’s dive into today's topics. This is what we have for you today:

• 💡 The Need for New Execution Environments Beyond EVM

• 🔢 Metric of the Week

• 💎 Gem of the Week

TL;DR

• The Ethereum Virtual Machine (EVM) is a messages-only VM that makes smart contract programming complicated, and it lacks an intrinsic understanding of what an asset is.

• This fundamental limitation within the EVM environment underscores a core challenge in establishing a secure and standardized DeFi foundation, leading to hundreds of hacks and the loss of billions of dollars.

• New execution environments that can inherently recognize and define assets are needed to create a more secure and standardized foundation for DeFi, as a secure foundation is fundamental for the real-world adoption of DeFi.

The Need for New Execution Environments Beyond EVM

Ok, let’s dive in👇

What is EVM?

The Ethereum Virtual Machine (EVM) is the core computing engine of the Ethereum network. It's a virtual machine that executes smart contracts, which are self-executing contracts with the terms directly written into code.

The EVM interprets compiled code, runs it on the Ethereum blockchain, and allows for interaction between different contracts. It also maintains a state of account balances and contract data.

EVM has undeniably shaped the landscape of Web3, enabling a myriad of applications from DeFi to DAOs. Its compatibility has become a standard in the blockchain space.

However, this widespread adoption of EVM compatibility is not without its drawbacks. The recurring incidents of hacks and security breaches have raised serious questions about the robustness of the EVM and underscored the desperate need for a more secure execution environment.

Is EVM compatibility a blessing or a curse for blockchains?

As we delve into this topic, we will explore why the blockchain space is urgently calling for a more robust execution environment that can enable enhanced security.

2023: EVM-Based Platforms Under Continuous Siege

In 2023, the cryptocurrency landscape faced a series of high-profile breaches, leading to significant financial setbacks.

In the first quarter, more than $222 million was lost in 52 flash loan and oracle manipulation exploits. Binance Smart Chain (BSC), which is an EVM chain, accounted for 139 incidents, the highest number for the period.

The second quarter continued this alarming trend, with over $300 million lost. BSC experienced 119 security incidents, resulting in losses of around $70 million, followed by Ethereum, which saw 55 incidents netting hackers over $65 million.

Now, Curve Finance, one of the prominent decentralized exchanges on the Ethereum network, has become the latest victim of this year.

Curve Finance Hack

The Curve Finance hack that occurred on July 30, 2023, led to significant losses across several liquidity pools, totaling approximately $70 million.

Here's an overview of the incident:

Cause of the Exploit: The vulnerability was found in Vyper, a Pythonic programming language used for Ethereum smart contracts. Versions 0.2.15, 0.2.16, and 0.3.0 of Vyper contained issues that made some smart contracts susceptible to re-entrancy attacks.

Initial Exploit: The attack began with an exploit of JPEG'd's pETH-ETH pool for $12 million, but an MEV bot front-ran the attacker, possibly in a white hat effort.

Subsequent Attacks: Other pools were targeted, including:

Alchemix DAO's alETH-ETH for $20 million

Metronome DAO's sETH-ETH for $1.6 million

Curve's CRV/ETH pool for $18 million

$22 million worth of CRV tokens drained from Curve's swap pool

Why the problem lies with EVM rather than with the Vyper language

The Curve hack underscores a critical issue in the EVM concerning the architecture of assets and their handling logic within smart contracts.

In the EVM, assets are treated as data within smart contracts, and the logic for handling those assets must be explicitly defined by the contract's developer. There's no intrinsic understanding or standardization of assets within the EVM itself. This lack of standardization and intrinsic understanding led to the vulnerability that was exploited in the Curve hack.

The specific issue was related to re-entrancy, where the contract's logic allowed for unexpected behavior when called multiple times within a single transaction. Since the EVM doesn't provide standardized asset handling logic, each contract must define its own rules for managing assets. This increases the complexity and risk of errors, as seen in the Curve incident.

So now let’s take a deeper look at how things work in the EVM world 👇

Introduction to messages only Execution environments

Messages-only virtual machines, such as the EVM, are a specific type of computing environment that operates on the principle of message passing to execute transactions and manage assets on a decentralised ledger.

Here's a detailed walkthrough of the concept and how it works:

Smart Contracts and Data:

In a messages-only VM like the EVM, smart contracts are self-contained machines that contain two main components:

Data: This includes information like a list of accounts and balances to represent who owns a token, and any other data that may need to be recorded and updated, such as privileged accounts that can modify the smart contract.

Rules: These are the methods and functions that form the smart contract logic, governing how the data can be updated as part of a transaction.

Developers can build tokens by combining the data and rules.

For example, an ERC-20 token contract will have data representing the accounts and balances of the token holders and rules defining how these balances can be transferred or modified.

Since a token is essentially a list of balances inside a specific smart contract (e.g., USDC inside the USDC contract), it cannot be "sent" or moved outside of that contract.

If a user wants to perform a transaction involving multiple tokens, messages must be sent to the respective smart contracts to request the necessary balance changes.

For example, in a token swap on a Decentralized Exchange (DEX), the DEX sends separate messages to the smart contracts of Token A and Token B to execute the swap.

Complexity of Messages Only VM

1. Messages Only VMs Lack The Intrinsic Understanding of Assets

In messages-only VMs, the platform itself doesn't inherently recognize what an asset is. This lack of intrinsic understanding leads to several challenges:

Definition of Account and Token:

• Account: An account is a balance entry for a given public key in a smart contract, repeated for each token held. This means that the platform doesn't recognize an account as an entity with specific attributes or rights but merely as a numerical value associated with a key.

• Token: A token is a list of balances for public keys, governed by a developer's smart contract logic. The platform doesn't understand the token as an asset with intrinsic value or specific properties but as a data structure within a contract.
  

This lack of understanding means that the platform cannot enforce standard rules or behaviors for assets, leading to increased complexity and potential vulnerabilities.

A. Unauthorized Token Transfers

The lack of intrinsic understanding of assets also leads to challenges with unauthorized token transfers:

• Sending Without Permission: If the developer retains privileged access to the smart contract, they could change your balance inside it without your permission. This can lead to fraudulent activities or manipulation.

• Receiving Without Permission: Anyone can send you tokens without your permission, as your account is just a line item in someone else's smart contract. This lack of control can be exploited by malicious actors to disrupt the normal functioning of applications.

For example, a hacker can deposit tokens in your account outside of your application's standard process, which can ruin calculations that leverage that balance. This makes it extremely challenging to code secure smart contracts, as developers must always account for these risks.

B. Complexities in Tracking Balances

The lack of intrinsic understanding of assets extends to complexities in tracking balances:

• Reserve Caches: Some applications must keep track of their account-balances in other contracts, known as reserve caches. This adds an extra layer of complexity and requires meticulous management to ensure accuracy.

• Imbalances in Liquidity Pools: Unauthorized token transfers can ruin internal accounting algorithms, leading to imbalances in liquidity pools. This complexity is exemplified in cases where liquidity pools become imbalanced due to direct token transfers to addresses.

These complexities require developers to create additional logic to manage balances and ensure that the system's internal accounting remains consistent. Any mistakes in this area can lead to significant vulnerabilities.

C. Limited Authorizations

In messages-only VMs, authorizations are limited to addresses, creating challenges in developing complex systems:

• Difficulty in Transferring Access Rights: The limitation to addresses makes it challenging to transfer access rights or build complex permissioned applications. This hampers the development of intricate systems that require nuanced permission structures.

• Lack of Flexibility: The restriction to address-based authorizations reduces the flexibility in designing smart contracts that need to manage different levels of access or permissions dynamically.

This limitation in authorization mechanisms can lead to a lack of functionality in the smart contracts and may require developers to create cumbersome workarounds, increasing the risk of errors and vulnerabilities.

2. Developers Must Create All Asset Logic

In messages-only VMs, developers are burdened with the responsibility of creating all asset logic. This introduces several complexities and challenges:

Universal Properties of Assets

Assets in any financial system should have certain universal properties. These properties ensure the integrity, security, and functionality of the assets within the system:

Ownership: Assets should be owned by someone or something and can be allowed to be transferred.

Transferability: Assets should be transferable between parties without unauthorized duplication.

Prevention of Double-Spending: Assets should not be spent twice, ensuring that each unit of the asset is unique and can only be used once in a transaction.

Preservation During Transactions: Assets should not get lost or go missing during a transaction; they should net to zero.

However, messages-only platforms do not provide this standard logic to developers.

A. It's the Developer's Responsibility and Burden to Implement Asset Logic

In messages-only VMs, smart contract developers bear the entire responsibility for implementing all asset logic. This includes not only the universal properties mentioned above but also the specific rules and functions governing how assets are created, transferred, and managed within the contract.

B. Lack of Standardisation

In this context “standardisation” refers to the establishment of common rules, protocols, or guidelines for implementing asset logic across different contracts.

Without standardization, each developer or team may create their own unique way of handling assets within a contract, leading to a bespoke or customized approach for each contract.

This can make it difficult to combine or interact with other contracts, as they may have different rules or methods for handling similar tasks.

The means that even a slight mistake in one implementation can lead to potential vulnerabilities across multiple contracts. The absence of a common guideline leaves developers navigating a complex and risky landscape.

3. Complex and Uncomposable Transactions

Now the complexities extend to transactions.

Messages-only VMs introduce a series of complexities in handling transactions, which can lead to security risks, inefficiencies, and unexpected behaviors.

A. Lack of Control Over Transactions

In messages-only VMs, users are unable to define specific outcomes for transactions. They must rely solely on the execution logic embedded within the smart contract.

Flawed Logic: If the logic within the contract is flawed, it can lead to unintended consequences. For example, a poorly coded transfer function might allow unauthorized users to withdraw funds.

Malicious Crafting: Worse, if the logic is maliciously crafted, it can lead to outright theft or other harmful actions. An attacker who gains control over a contract might alter its logic to divert funds to their own account.

No User Safeguards: Since the VM doesn't inherently understand the nature of the assets, users can't enforce specific conditions or safeguards. They are left at the mercy of the contract's code, without the ability to stipulate what must happen in a transaction or else fail the transaction.

B. Blind Signing of Transactions

The process of "blind signing" transactions, where users sign without knowing what they're signing, adds another layer of risk.

Lack of Transparency: Users are presented with only a hash of the transaction, appearing as a string of random letters and numbers. They don't actually know what it is they're signing, leading to a lack of transparency and understanding.

Potential for Exploitation: This lack of understanding can be exploited by hackers. For instance, a compromised website might trick users into signing a transaction that approves a malicious actor to spend their tokens.

Common Attack Vector: Blind signing has become a common attack vector in the crypto space, with numerous hacks exploiting this vulnerability.

C. Complexity in Calling Multiple Contracts

In messages-only VMs, users can only directly call one contract in a transaction. Complex transactions require their own smart contract, leading to an intricate web of calls.

Routing Messages Downstream: Developers have to contend with complex logic that routes messages downstream, and downstream again, to other contracts. Understanding all the permutations of how this logic interacts with multiple other smart contracts becomes a daunting task.

Increased Error Opportunities: The more complex the calling structure, the more opportunities there are for errors or vulnerabilities. A mistake in one part of the chain can have cascading effects, leading to failures or security breaches in other parts.

D. Re-Entrancy Issues

Re-entrancy is a phenomenon where a smart contract is called multiple times within a single transaction. While this can be a necessary feature in some cases, it introduces a high level of complexity.

Developers must carefully manage the order of operations within their contracts to prevent unexpected behavior.

If the logic is ordered incorrectly, it can lead to hacks and exploits.

For example, if a contract's balance is updated after an external call rather than before, a malicious contract could repeatedly call the original contract, draining its funds.

Re-entrancy has been at the heart of numerous DeFi hacks, highlighting the challenges and risks associated with this feature in messages-only VMs

Here is a long list of reentrancy attacks to date, which have resulted in the loss of billions of dollars.

EVM Compatibility: A Solution to Liquidity or a Path to Vulnerability?

Currently, EVM compatibility is focused on accessing more liquidity for blockchains to draw in users, especially as many ecosystems face a liquidity crunch. While this approach aligns with Ethereum's dominance in the blockchain space, it's a short-sighted move.

The accessibility to liquidity through bridges adds risk, as interchain bridges are among the most vulnerable parts in the blockchain space. EVM compatibility in a blockchain may introduce security risks, particularly from smart contract vulnerabilities, potentially exposing the network to various exploits.

Moreover, users interested in EVM-based dApps are likely already using Ethereum or other platforms like BSC, Arbitrum, Optimism, Polygon or Base.

In the long term, EVM compatibility may prove to be of limited value.

Why New Execution Environments Are Essential for the Future of Decentralized Finance?

New/Alternative execution environments have the potential to redefine the DeFi landscape by inherently recognizing and defining what an asset is, how it should behave, and ensuring adherence to universal properties. This fundamental shift can create a more secure and standardized foundation for decentralized finance.

Creating New Possibilities: These environments go beyond merely fixing existing problems. By providing a more flexible and intuitive framework, they can foster innovation and enable the creation of more complex and interconnected decentralized applications.

Enhancing Security: The standardization of asset understanding at a core level can reduce the risks associated with bespoke asset logic. This leads to a more robust environment where universal properties are consistently enforced.

Shaping the Future of DeFi: These alternative platforms can be at the forefront of this evolution, providing the tools needed to build the next generation of decentralized applications.

In conclusion, the move towards alternative execution environments is about more than overcoming the limitations of messages-only VMs. It's about forging a new paradigm where the understanding of assets is embedded within the system. This opens doors to new possibilities, enhances security, and sets the stage for a more advanced and resilient DeFi ecosystem.

Source used for writing this content:

• https://www.radixdlt.com/blog/comparing-virtual-machines-message-only-vs-asset-oriented

• https://www.radixdlt.com/blog/the-problem-with-smart-contracts-today

• https://www.smartcontractresearch.org/t/a-survey-on-ethereum-systems-security-vulnerabilities-attacks-and-defenses/98

That's it for this week. See you next Sunday!

LET US HEAR IT

What’d you think of this email? Tap your choice below 👇

It would mean the world if you took a second and be our Newsletter Testimonial. ✨ 

We’ll share all Testimonials on our Website and Twitter because your unique perspective and experiences with Just The Metrics could be a game-changer for others considering joining our community!

Refer 10 friends & get a FREE copy of our book, ‘A 3 Step Assessment Framework for Layer 1 Blockchains’📘

If you want to learn more abou crypto metrics and blockchain technical fundamentals give us a follow on Twitter or LinkedIn

@Dimoneymindset and @SoorajKSaju

DISCLAIMER: None of this is financial advice. This newsletter is strictly educational and is not investment advice or a solicitation to buy or sell assets or make financial decisions. Please be careful and do your own research.