For developers plying their trade in today’s rapidly scaling, blockchain-agnostic environment, deciding on the right approach to smart contract execution is paramount.
In this piece, I’ll review EVM’s credentials (Ethereum Virtual Machine) and SmartWeave as two distinct options for developers to consider. Full disclosure, we’re going on a deep dive! Before we get started, here’s a comparison table to give you a sense of both execution environments:
Key considerations for using EVM
EVM, initially implemented by Ethereum, is now the choice for most smart contract platforms, extending to Avalanche, BNB Chain and L2s like Arbitrum, Optimism, and more. Using EVM requires knowledge of Solidity, which can be 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 distributed networks, making it the go-to computer language for developers in the blockchain space.
While Solidity has a unique structure and syntax that can prove challenging for those considering Web3 development, it continues to draw a large influx of new learners. Furthermore, the EVM boasts a vast ecosystem of resources, tools, educational materials, and enthusiastic developers.
Even though EVM is widely considered the gold standard framework for building decentralized applications, it does have strict limiting parameters, which newly-found developers must learn to work within. A senior Solidity developer’s ability to optimize code for rigorous computation limits (in the form of gas limits) distinguishes them from the fresh-out-of-academy-type-dev. This model’s disadvantage is that it puts a huge emphasis on block space, which can become an extremely expensive facility.
Furthermore, the requirement for consensus-driven synchronization of computations at every block adds layer of complexity to the EVM’s design, acting as a significant roadblock to scaling efforts, especially given the sequential evaluation of all smart contract interactions.
A noteworthy consideration involves the unique storage model within the Ethereum Virtual Machine. In most programming languages, understanding low-level data representation is not crucial, but Solidity deviates from this norm. Given the significant cost associated with storage access on Ethereum-based networks, having a firm grasp on how data types are represented is essential. The shared global storage model across all contracts, regardless of their interaction, brings challenges.
The design introduces inefficiencies, forcing contracts to wade through extraneous data, slowing transaction times, and incurring unnecessary computational costs. These costs contribute to an increased financial burden for storing data on the platform, affecting developers and users. Additionally, the shared nature of storage could inadvertently amplify coding errors or vulnerabilities, leading to unintended consequences for unrelated contracts and potentially escalating rectification costs.
Introducing SmartWeave
On the other side of the aisle, SmartWeave is a paradigm for evaluating smart contract states on an immutable data layer like Arweave. SmartWeave’s distinct value proposition has far-reaching potential to enhance the creation of highly efficient dApps for a host of specific use cases – serving as a complementary framework to fill the gap where the EVM falls short. Because a data layer does not perform arbitrary computing, it places the responsibility for assessing the current contract state on the caller using a “lazy evaluation.”
To “lazy” evaluate the current state of a contract, the caller verifies and executes all contract interactions (Arweave transactions) from the contract’s inception to the present, reproducing the current state of the contract from scratch.
In essence, Arweave smart contracts consist of an ordered set of actions (C, I, Ts), with ‘C’ being the portion containing the contract code, ‘I’ being the fraction containing the initial state, and ‘T’ being a sequence of transactions that interact with the contract. When the client evaluates the state, it utilizes the code from C, the initial state from I, and applies each transaction after it (provided it is valid) based on the contract code. Got it? Good! Here is a visual overview of the architecture to help crystalise the concept:
SmartWeave is an architecture aimed at creating a reliable, fast, and production-ready smart contracting engine on Arweave. Its most popular implementation, Warp Contracts, is focused on delivering this exact goal. Warp is often described as “SmartWeave contracts on steroids” due to its ability to overcome some of the most significant obstacles associated with the default implementation of the SmartWeave protocol.
These obstacles include the lack of caching that leads to low performance, the absence of a reliable SmartWeave transaction gateway, and the inability to ensure contract security and determinism. In addition to its main function, the Warp SDK includes a finely-tuned caching layer that greatly enhances lazy evaluation efficiency.
The stack also includes user-friendly deployment and maintenance methods, customizable plugins that allow users to extend the SDK in any direction they desire, a dedicated smart contract explorer, a set of nodes for outsourcing execution and several other essential features. The Warp core team has created a range of proprietary plugins, including portable EVM tooling, EVM wallet support, EtherJS native support in the SmartWeave environment, and others. As of now, Warp supports JavaScript/TypeScript languages and WASM with Rust support.
Distinguishing EVM from SmartWeave Architecture
The EVM’s security is intrinsically linked to the consensus technology of its underlying blockchain. Likewise, SmartWeave also depends on the security and end-finality of Arweave’s blockchain, which is achieved by including blocks finalized using the SPoRa (Succinct Proofs of Random Access) protocol.
By design structure, EVM implements the fee market into the core protocol. The market fee scheme uses a first-price auction mechanism to determine transaction fees, where the highest bidder has their transaction processed first. The challenges associated with scaling the network become particularly apparent during periods of high demand, as seen with the global fee market design of the Ethereum Virtual Machine.
For instance, when an individual contract experiences considerable activity, such as a much-anticipated NFT mint, it inadvertently impacts all network users by escalating transaction costs, even for those not directly involved with the high-demand activity.
Arweave proposes an alternative approach to the traditional fee market by utilizing a single reward pool and merkle root for all data, called the endowment. Adding new data to the system updates the merkle tree and adds $AR tokens to the reward pool without causing an increase in computational overhead. To address the bottleneck of processing payments for data storage, Arweave uses a system of recursive bundles to settle multiple transactions in a single payment on the network.
Eventually, this could lead to trees of infinite depth that allow for ingesting all web data within a single transaction, eliminating the need for fee markets. Arweave’s transaction system allows users to execute transactions without a block inclusion fee, resulting in storage costs being the only expense for executing transactions, no matter the demand side.
SmartWeave is a sequenced array of Arweave transactions that benefit from the absence of a fee market for transaction block inclusion. This unique property allows unlimited transaction data without additional fees beyond storage costs. Furthermore, the open-ended design of SmartWeave enables developers to write the logic in any programming language, offering a refreshing alternative to the often rigid Solidity codebase.
Part 2 will be coming tomorrow, covering:
- Lazy Execution: An Alternative Perspective
- Assessing the suitability of EVM and SmartWeave
- SmartWeave Market Fit
Guest post by: Jakub Wojciechowski, CEO and Founder of Warp Contracts and RedStone
Credit: Source link
