Determining the right approach to smart contract execution is paramount for developers transacting in today’s rapidly expanding blockchain-agnostic environment.
This article reviews EVM Credentials (Ethereum Virtual Machine) and SmartWeave as two different options for developers to consider. Full disclosure, we’re digging deeper! Before we start, here’s a comparison table to help you understand both execution environments.
Key considerations when using EVM
Initially implemented by Ethereum, EVM is now the choice of most smart contract platforms and extended to L2 such as Avalanche, BNB Chain, Arbitrum and Optimism. Using EVM requires knowledge of Solidity, characterized as blockchain’s answer to JavaScript. As the language of EVM, Solidity has emerged as the de facto programming language for smart contracts on decentralized networks, making it the go-to computer language for developers in the blockchain space.
Solidity has a unique structure and syntax that can be difficult for those considering Web3 development, but it continues to attract a large influx of new learners. Additionally, EVM boasts a vast ecosystem of resources, tools, teaching materials, and dedicated developers.
EVM is widely considered the gold standard framework for building decentralized applications, but it has strict limiting parameters that new developers must learn how to work within. Advanced Solidity developers have the ability to optimize their code for tight computational limits (in the form of gas limits), which sets them apart from developers fresh out of the academy. The downside of this model is that it can be a very expensive facility as block space is very important.
Moreover, the requirement for consensus-driven computational synchronization across all blocks further complicates the design of EVMs and presents a significant obstacle to scaling efforts, especially considering the sequential evaluation of all smart contract interactions.
Notable considerations include the unique storage model within the Ethereum virtual machine. In most programming languages, understanding low-level data representation is not important, but Solidity deviates from this standard. Given the enormous costs associated with accessing storage on Ethereum-based networks, it is essential to have a firm grasp on how data types are represented. A shared global storage model across all contracts poses challenges regardless of interaction.
This design creates inefficiencies, requiring contracts to process unrelated data, slowing transaction times, and incurring unnecessary computational costs. These costs lead to an increased financial burden for storing data on the platform, which affects developers and users. Additionally, the shared nature of storage can inadvertently amplify coding errors and vulnerabilities, leading to unintended consequences for unrelated contracts and increased remediation costs.
Introducing SmartWeave
across the aisle, smart weave A paradigm for evaluating the state of smart contracts in immutable data layers like Arweave. SmartWeave’s clear value proposition serves as a complementary framework that fills the gap where EVM is lacking, and has far-reaching potential to enhance the creation of highly efficient dApps for a host of specific use cases. increase. Since the data layer does not perform arbitrary computation, it is the caller’s responsibility to evaluate the current contract state using “lazy evaluation”.
For a “lazy” evaluation of the current state of the contract, the caller validates and executes all contract interactions (Arweave transactions) from the start of the contract to the present, recreating the current state of the contract from scratch. To do.
Essentially, an Arweave smart contract consists of an ordered set of actions (C, I, Ts). ‘C’ is the part containing the contract code, ‘I’ is the part containing the initial state, and ‘T’ is the set of transactions that interact with the contract. When the client evaluates state, it takes the code from C, the initial state from I, and applies each subsequent transaction (if enabled) based on the contract code. Did you take it? good! Below is a visual overview of the architecture to help flesh out the concepts.
SmartWeave is an architecture aimed at creating a reliable, fast and production-ready smart contract engine on top of Arweave. The most common implementation is warp contract, is focused on achieving exactly this goal. Warp is often referred to as a “hardened SmartWeave contract” due to its ability to overcome some of the most important obstacles associated with default implementations of the SmartWeave protocol.
These obstacles include lack of caching leading to poor performance, lack of reliable SmartWeave transaction gateways, and inability to ensure security and determinism of contracts. In addition to its main features, the Warp SDK includes a finely tuned caching layer that greatly improves the efficiency of lazy evaluation.
The stack includes user-friendly deployment and maintenance methods, customizable plugins that allow users to extend the SDK in any direction they want, a dedicated smart contract explorer, a set of nodes for outsourcing execution, and a few other important things. functions are also included. The Warp core team has created various proprietary plugins such as a portable EVM tool, EVM wallet support, and his EtherJS native support in the SmartWeave environment. others. Warp currently supports JavaScript/TypeScript languages and WASM with Rust support.
Distinguishing between EVM and SmartWeave architectures
EVM security is inherently linked to its underlying blockchain consensus technology. Similarly, SmartWeave also relies on the security and final finality of Arweave’s blockchain. This is achieved by including blocks finalized using the SPoRa (Succinct Proofs of Random Access) protocol.
By design structure, EVM implements a toll market into its core protocol. A market commission scheme uses a first-price auction mechanism to determine transaction fees, with the highest bidder processing the transaction first. The challenges associated with scaling the network are especially pronounced during times of high demand, as seen in the global pricing market design of the Ethereum virtual machine.
For example, substantial activity, such as the long-awaited NFT minting, on individual contracts can drive up transaction costs and unintentionally impact all network users, even those users who are not directly involved in the high-demand activity. affects
Arweave proposes an alternative approach to traditional fee markets by utilizing a single reward pool called donations and the Merkle root of all data. Adding new data to the system updates the Merkle tree and adds $AR tokens to the reward pool without incurring additional computational overhead. To address the payment processing bottleneck of data storage, Arweave uses a system of recursive bundles to settle multiple transactions with his single payment over the network.
Ultimately, this could lead to infinitely deep trees that can capture all web data within a single transaction, eliminating the need for fee markets. Arweave’s transaction system allows users to execute transactions without block inclusion fees, so the only cost to execute a transaction is the cost of storage, regardless of the demand side.
SmartWeave is a sequenced array of Arweave transactions that benefits from the lack of a fee market for including transaction blocks. This unique property allows unlimited transactional data with no additional charges beyond storage costs. Additionally, SmartWeave’s open-ended design allows developers to write logic in any programming language, providing a fresh alternative to the often rigid Solidity codebase.
Part 2 will be published tomorrow and will cover:
- Deferred Execution: Another Perspective
- Evaluation of the suitability of EVM and SmartWeave
- Market suitability of SmartWeave
Guest Posted by: Jakub Wojciechowski, CEO and Founder warp contract and Akaishi
