The Road to MainNet: Key Takeaways from The Tech Talk With Prasana, Head of Engineering, DeFiChain Labs

In the fast-paced realm of blockchain and decentralized finance, evolution is the name of the game. As we stand on the threshold of a significant leap forward, it's our pleasure to bring you the latest edition of Tech Talk.

In this installment, we dive deep into the heart of Metachain's final launch, uncovering the intriguing developments, implementations, and milestones that have paved the path to this exciting moment.

A Roadmap Overview

Looking at the evolutionary path of DeFiChain, initially built as a UTXO-based blockchain that only interacted with the Bitcoin network. DeFiChain carved out a successful DeFi niche within the Bitcoin community, offering core DeFi features like decentralized exchanges (DEXes), collateralized debt positions (CDPs), and governance mechanisms.

With the roll-out of Changi, DeFiChain expanded its capabilities to support the Ethereum Virtual Machine (EVM), making it easier to create decentralized applications (dApps).

The next major development on the horizon for DeFiChain is the integration of a cross-chain protocol. Already capable of interfacing with the Bitcoin network, DeFiChain aims to evolve to allow a single node to validate and authenticate transactions for both its own blockchain and the Bitcoin blockchain.

DeFiChain currently interacts with the Bitcoin network through a Simplified Payment Verification (SPV) layer, enabling atomic swaps. However, the future vision involves direct communication with the entire Bitcoin network, essentially allowing DeFiChain to function as a Bitcoin node.

Additionally, thanks to the Metachain layer's EVM compatibility, DeFiChain will be able to interact with the Ethereum network as well. This cross-chain functionality debuts following the mainnet launch. Implementing this feature will be transformative for users who wish to engage with both blockchain ecosystems—Bitcoin and Ethereum effortlessly.

MetaChain’s Key Milestones

The following graphic outlines the key achievements our team and community have collaboratively focused on. Kicking things off in late April was the launch of "FloppyNet," a pre-alpha version offering early-stage prototypes with no safety guarantees, including the possibility of rollbacks. The community began stress-testing this early version, and their input proved invaluable. Numerous bugs were discovered and addressed thanks to this active community participation.

Next in line was "Changi," a more stable network version where the team committed to not rolling back any features, bugs, or otherwise. This version saw the introduction of bug fixes as well as new functionalities.

Just a couple of weeks ago, Changi underwent a 'clean slate' operation to eliminate temporary solutions that were previously installed, leading to a more streamlined network and the preliminary release of DST20. However, some unresolved issues remain, such as node performance limitations and occasional system crashes.

By the end of August (indicated by an orange dot), the team is optimistic about migrating all functionalities to the third testnet. Green dot marks our intended timeline to launch the mainnet.

MainNet: The Current Status

Let's dive deeper into the current status of the project timeline, marked at week 31. The Changi network is highlighted by a purple bar in the associated graphic. The immediate objective is to stabilize Changi within this week, with a transition to testnet 3 planned for the early part of week 32.

Testnet 3 serves as a stable mirror of the MainNet, designed for developers to use as a representative testing ground. With most existing issues already addressed and having undergone rigorous consensus testing, the Changi network is nearly ready for this move; only the SD20 feature remains to be thoroughly tested.

For week 31, a minor release was introduced to bring further stability to the network, followed by a beta release aimed at implementing prompt refinements. The core aim is to pave the way for community testing. Upon ensuring testnet 3's robustness, the stage will be set for the mainnet fork.

To summarize and concentrate on the key implications for the upcoming version 4.0 node, here are the highlights:

• VM & RPC: Version 4.0 will include Virtual Machine (VM) support, specifically focusing on Ethereum Virtual Machine (EVM) compatibility. This VM will work closely with the RPC layer, which governs how Ethereum-based tools interact with the VM.
• Wallet ERC-55 Support: The DeFi wallet in this update will be compatible with ERC-55 addresses. For users with pre-existing keys, this will ensure a smooth transition.
• Feature Limitations: While the new version includes functionalities catering to both Bitcoin and Ethereum ecosystems, it's important to note that not all features, such as TapRoot, are accommodated. Future discussions will address these gaps.
• DUSD Vaults: This new feature removes the constraints related to DFI requirements. Its activation or deactivation depends on governance decisions.
• Staking: The update will support BECH32 addresses for staking rewards, allowing lightwallet addresses to be designated as reward destinations, thereby simplifying the receipt of staking benefits.
• Tokens: Token splits on-chain have always been supported, but the new version adds fractional split capabilities, offering more flexibility in token management.
• Governance: A noteworthy change is the introduction of 'neutral votes,' allowing for a more nuanced approach to governance beyond the previous binary voting system.

Upcoming Introduction of New RPCs

New Remote Procedure Calls (RPCs), such as Vmmap, Address Map, and Transfer Domain, are slated for introduction. Vmmap will furnish cross-domain data, Address Map will offer various format representations for wallet keys, and Transfer Domain is pivotal for seamless navigation across different domains like EVM and DVM.

Light wallets are on track to support both Transfer Domain and Address Maps. Significant progress has been made, and all features should be in place by the time of the mainnet launch.

An Overview of Transfer Domain

Delving into the specifics of the RPCs and Transfer Domain, here's a simplified rundown: Initially, Transfer Domain will facilitate operations between DVM and EVM, with UTXO support planned for future inclusion. For now, mechanisms exist for converting UTXO to DVM tokens.

Still, the Transfer Domain will eventually handle this function, although this is slated for a date after the mainnet launch. Transfer Domain enables the fluid transfer of tokens between DVM and EVM platforms. Currently, it is restricted to supporting key tokens (DAT tokens) subject to governance approval, not user-created custom tokens.

Transferring a token from DVM to EVM will decrement the token amount in DVM and correspondingly appear in the EVM wallet, represented as an ERC20 token.

For example, if a token holds an ID of 10 in the DVM ecosystem, it will manifest in the Ethereum system as a contract with a specialized address format, like 0xFF followed by a namespace and the ID—here, 10. Such contracts will be auto-deployed by the node, accessible via the ERC20 interface just like any other Ethereum-based token.

Governance Features and Tracking

Developers interested in the on-chain specifics will find several governance attributes to explore. Transfer Domain comes equipped with high-level attributes outlining its capabilities and directions. New rule sets, gas targets, and gas caps have been set up for both DVM and EVM, all of which are documented in the governance attributes for further scrutiny.

Another governance attribute will track the volume of tokens transferred from DVM to EVM, all listed under the "live economy" namespace. This accounting feature is one of the final touches that will be added before achieving production readiness.

From a node consensus standpoint, these elements serve as validation checks, guaranteeing accurate transactional entries and exits, and will be part of the "live features" that offer insights into the node's operational intricacies.

Understanding the Fee Structure

Within the block architecture, the left side (see image below) comprises the standard block featuring the DVM, EVM, and UTXO, all amalgamated into a single unit. While UTXO and DVM continue to function as they currently do, all fees are pooled together and credited to the miner as the UTXO fee.

For EVM transactions, compliance with EIP-1559 means that these fees are also aggregated. The priority fees are allocated as tokens within the DVM ecosystem. Hence, miners obtain both UTXO fees and DVM token fees conforming to EIP-1559 guidelines. Any non-priority fee, in line with EIP-1559, is incinerated and sent to the burn address.

Each subsystem is responsible for its own fee management, while a broader validation framework ensures accurate accounting across all domains.

Given that the testnet environment has had its limitations, it's not the most accurate metric for base fee calculations. Nonetheless, following EIP-1559, a 12.5% fluctuation in the base fee is expected based on network usage. Adjustments to the gas target and gas limit can be enacted dynamically via the governance mechanism.

Although the fees are minimal on the testnet, this is not a reliable indicator. Fees in the EVM scale according to the type of operations performed, mirroring the Ethereum model. The deployment of Sputnik VM follows this scaling mechanism. Any discrepancies between mainnet and testnet behaviors will be observed and acted upon.

What's On The Horizon

Security & Testing

Focus areas in the recent weeks include fortifying security measures and conducting exhaustive tests. Contributions from community developers for further testing are highly encouraged.

Migrating to DST20

Migration of existing tokens within the testnet is underway, requiring meticulous attention. This process is expected to be completed in the coming days.

Code Refinements

Ongoing refactoring aims to bolster node performance, with the immediate goal being to enhance stability and resolve issues like random crashes.

Storage & Data

While the initial emphasis has been on integrating features, future efforts will pivot towards performance improvements and better data management.

Performance Enhancements

While stability remains a near-term priority, there is a projected 30% improvement in performance slated for the coming week. Plans include parallelizing EVM transactions to increase efficiency.

Upcoming Ethereum Tooling RPCs

RPCs, which have been deferred due to their complexity, are scheduled for the coming weeks. Some of these are crucial for mainnet launch, while others will appear in later releases.

If you're interested in exploring further or have any questions related to development, you're welcome to request an invitation to our specialized Discord server for developers here: LINK