Exploring Mainsail EVM Changes

We are excited to share our first blog post about the new additions and changes coming with Mainsail’s EVM integration. This post will cover some of the general changes that EVM is bringing to Mainsail and ARK, with more details to come in future posts.

Over the past few months, our Mainsail team has been working hard on integrating EVM within Mainsail. Last week, we reached a significant milestone with the initial EVM prototype successfully running on a new internal network. This will help us improve, fix, and get it ready for the public testnet.

There are still a few things we need to work on, and we will have to reset the internal EVM prototype network occasionally. However, the current state is feature-complete enough for experimenting.

If you missed it, you can also read the Core vs Mainsail blog post, which outlines the general differences between the current Core and Mainsail (before EVM integration).

#General Overview of Changes

• Mainsail now includes an EVM implementation based on revm .
• Wallet addresses now use cryptographic hash functionKeccak256 (the same as Ethereum).
• Transaction signatures now use a more modern version of Schnorr, replacing the legacy Bitcoin Cash version.
• A new evm-call transaction type has been added (type=10) to interact with the EVM.
• Existing transaction types remain unchanged except for the address and signature scheme changes.
• Fees for EVM transactions depend on gas usage, while fees for existing transaction types remain unchanged.
• An additional JSON-RPC API will be developed for reading EVM data.
• Once the public network goes live, the faucet will also send DARK20 tokens in addition to native DARK.
• The Mainsail TX Tester will get additional features to make testing EVM integration easier.

#Addresses & Signatures

The Mainsail EVM network uses a different address and signature schema from the existing testnet, while still using ECDSA public and private keys.

Here are the changes to wallet addresses and transaction signatures:

• Keccak256 is the algorithm used to derive an Ethereum wallet address from a public key.
• Schnorr (New) is a modern version of the Schnorr signature scheme, widely adopted compared to Schnorr (Legacy), which is mainly used by Bitcoin Cash and V3.

Since the key pairs are still based on ECDSA, migrating between old and new addresses is possible, which is necessary for the production network.

#EVM

The Mainsail EVM supports all smart contracts that run on Ethereum, based on the latest Shanghai upgrade. The EVM spec is managed via milestones, allowing Mainsail to upgrade to newer EVM specs seamlessly.

You can develop smart contracts as usual (e.g., using Hardhat or OpenZeppelin) and deploy the bytecode on Mainsail using the EVM Call transaction.

There are some differences, which will be detailed in the future. One key difference is that the native token balance is not exposed to the EVM (e.g., account balance is always 0 inside a contract). This is still being evaluated.

#REVM Integration

Our project uses revm for the Ethereum Virtual Machine. This decision was made after careful research because revm offers several benefits:

• It is built with Rust, known for its speed and security.
• It integrates smoothly with Node.js through napi-rs .
• It provides high performance, essential for our needs.
• It is trusted and used in production by other notable projects, such as reth .

These factors combined make revm the ideal choice for our project.

#EVM Call Transaction

We have introduced a new transaction type for EVM calls (type=10), available in the @mainsail/crypto-transaction-evm-call package. You can use its transaction builder by registering the service provider on your Application instance.

This transaction allows for deploying new contracts (when recipientId is not set) and executing contract code (when recipientId is set to a contract).

The transaction fee is in gwei, unlike existing transaction types. You will also need to provide a gasLimit as part of the asset.

Each EVM Call outputs a transaction receipt, which includes fields like success, logs, output, gasUsed, and more.

When api-sync is enabled, receipts are synced to PostgreSQL and stored in the receipts table. You can query receipts using the /receipts endpoint of the HTTP API or through the JSON-RPC API.

#Gas & Fees

For current transaction types, fees remain unchanged. EVM call transactions work differently; the actual fee is deducted after the transaction is executed. However, to enter the transaction pool, the sender must have a balance covering the theoretical maximum gas usage (gasLimit * gwei * nativeFeeMultiplier).

To know the actual gas used, you need to check the transaction receipt.

A native fee multiplier has been added to the milestones to convert gas usage to the native token. The actual numbers may change.

#DARK20

An ERC20-compatible token, DARK20, has been deployed on the EVM internal testnet. This token will be used for testing and will also be one of the first tokens available when the public network goes live.

#Faucet

The current public network faucet will also send an equivalent amount of DARK20 to your address once the public network goes live. Initially, you can use the TX Tester script to interact with the DARK20 contract until other products are ready for EVM use.

#TX Tester Updates

The TX Tester script will be updated to support EVM Deploy, EVM Call, and EVM View actions.

Initially, it will be the primary way to access the contract state, such as checking a token balance.

#JSON-RPC API

Mainsail includes a JSON-RPC API for querying various information.

Only a subset of the full spec is implemented due to technical differences and use cases. It is still a work in progress.

The JSON-RPC is part of the @mainsail/evm-api package and listens on port 4008 by default.

#API HTTP - Changes

A new /receipts endpoint has been added to query transaction receipts.

This endpoint provides easy access to receipts while the explorer and JSON-RPC API are being developed. It supports querying receipts via parameters like ?txHash, ?sender, and ?recipient.

The content of a receipt is not interpreted, so you need to do it yourself using the contract ABI and a library like ethers.js to decode the logs/output.

#Performance

With the EVM integration, we have also made performance improvements to the transaction pool and general consensus. These changes have significantly increased throughput. We will share more details in a dedicated performance blog post soon.

#What’s Next?

Our Mainsail team will continue improving EVM integration based on initial prototype testing. We will work on:

• Including the EVM state hash when creating a block.
• Research native account balance support.
• API improvements.
• Further performance benchmarks and optimizations.
• Compatibility with legacy state (e.g., V3 snapshot).

We will also integrate Mainsail’s EVM support into products like ARK Vault and ARK Scan for easier testing and further improvements. Some decisions are still pending, and our team will focus on these soon.

We will keep everyone updated on the progress as we complete several rounds of internal testing, fix initial issues, and work on integrations.

Stay tuned for more blog posts about Mainsail and EVM in the coming weeks!

#Follow on Twitter (X)

Stay updated on all our new releases by following us on X (formerly Twitter). Check our blog regularly for the latest updates. We also publish a weekly development report, so you can track our progress and join us on the journey toward realizing a decentralized future.