Since our last update, we’ve been busy refining and expanding Mainsail EVM across multiple fronts. From new features and performance improvements to foundational refactors, things are moving fast — and we’re now in the final stretch of development and fixes before launching the initial Mainsail EVM public testnet. Here’s a closer look at what’s been happening behind the scenes.
New Block Structure & Serialization Enhancements
One of the key changes is the addition of the LogsBloom field to blocks. This 256-byte (2048-bit) data structure allows for efficient checks to determine whether a block might contain specific log entries, without scanning each one individually, making log lookups much faster.
We’ve also refined how block gas is calculated. Instead of summing up transaction gas limits, we now sum only the actual gas used, giving a more accurate view of block consumption.
Transaction sizes are now stored using a 4-byte uint32 instead of 2 bytes, paving the way for large transactions that might fill an entire block. This change future-proofs the system for increasing block sizes and gas limits.
In another step toward Ethereum compatibility, the v signature value for transactions now uses 0 and 1, replacing the older 27 and 28 values inherited from Bitcoin — a change aligned with Ethereum clients.
Dependency & Tooling Updates
We’ve updated nearly all project dependencies to their latest stable versions. Importantly, we lock package versions in production builds to ensure stability and prevent unexpected behavior from packages that might not follow strict semantic versioning.
Core development tools like TypeScript and ESLint received major updates, and we’ve made the necessary code adjustments to accommodate new rules and breaking changes.
On the Rust side, we’ve upgraded to 2024 Edition, along with a full update of all Rust dependencies. Our CI pipelines now run on Node.js 22.x LTS, ensuring we’re aligned with the latest runtime improvements.
Cleaner, Leaner Codebase
We’ve introduced a new package, blockchain-utils, which centralizes shared logic such as RoundCalculator, SupplyCalculator, and FeeCalculator. Previously, these were scattered in the kernel package, but this move helps keep responsibilities well-separated.
Utility functions like assertions and IP validation now live in a general utils package, and we’ve taken the opportunity to remove unused legacy code like ExpirationService and DynamicFeeMatcher, which no longer align with the updated transaction handling mechanism.
Legacy Compatibility
We’re also ensuring smoother migration paths by adding legacy support for second signatures. The system detects whether an account has a registered second signature and, if present, validates it using an extended RLP serialization format.
Since we plan to import data from the existing ARK network, we’re implementing a block offset mechanism. This means Mainsail’s genesis block won’t start at height 0 — it will follow directly after the latest block from the current network.
Smarter EVM Handling
Our EVM implementation now supports multiple pending commits at the same block height. This is especially useful when a block doesn’t reach consensus in the first round. The system caches multiple processed block versions, avoiding redundant computation. Once a block receives +2/3 validator commits, it becomes finalized and can no longer be reverted.
Database Unification
We’ve consolidated our data storage by removing the standalone LMDB implementation from @mainsail/database and migrating it entirely into our Rust EVM implementation, which uses the heed library (also based on LMDB). This integration enables atomic commits, where all relevant data — from state changes to blocks, transactions, and commit proofs — are stored in a single, fail-safe operation.
Aligning with Ethereum Naming Conventions
To make Mainsail’s API and internal structures more familiar to Ethereum developers, we’re undergoing a major refactor to align field names with Ethereum standards. This will affect both the public API and internal code structures.
Here are a few examples of the field changes:
Block Field Mappings
| Old | New |
|---|---|
id |
hash |
height |
number |
previousBlock |
parentHash |
stateHash |
stateRoot |
numberOfTransactions |
transactionsCount |
totalGasUsed |
gasUsed |
totalAmount |
amount |
totalFee |
fee |
payloadLength |
payloadSize |
payloadHash |
transactionsRoot |
generatorAddress |
proposer |
Transaction Field Mappings
| Old | New |
|---|---|
id |
hash |
senderAddress |
from |
recipientAddress |
to |
gasLimit |
gas |
sequence |
transactionIndex |
blockId |
blockHash |
blockHeight |
blockNumber |
What’s Next?
In the coming few weeks, we plan to complete the remaining features needed to launch a new network that chains directly from our existing development testnet. As part of this process, we’ll later on introduce support for registering new BLS public keys. Validators will then be able to register their BLS keys on the devnet, which will then be used by validators in Mainsail to sign consensus messages and block proposals.
We’re incredibly excited about the progress and can’t wait to welcome early adopters and contributors onto the Mainsail EVM testnet soon. Stay tuned — the sails are almost set.
Follow on Twitter (X)
Follow us on X (Formerly Twitter) and keep checking the blog to stay up-to-date on all of our new releases. We post a weekly development report so you can easily see what we’ve been up to and follow along our journey towards making your decentralized future a reality.
