Understanding EVM, ERC20 module, Migration Tool
Welcome to the April issue of Hash Out! In this issue we discuss the upcoming EVM module upgrades, including the ERC20 Module, Feemarket Module and also the Migration Tool, all undertaken to improve EVM compatibility in the Function X ecosystem and support for full DApps functionalities.
Background
The Ethereum Virtual Machine (EVM) is what allows developers to build decentralized applications which is done through smart contracts written in Solidity then compiled to lower-level machine bytecode. In the Ethereum blockchain, EVM plays an essential role that gives developers a sandboxed virtual stack embedded within each full Ethereum node that helps to create and implement smart contracts over Ethereum.
Currently on the Testnet, f(x)Core is compatible with EVM, enabling developers to write, deploy, and port smart contracts and dApps without writing from scratch. In addition, when compared to the Ethereum chain, this can be done with a faster consensus mechanism, with cheaper gas fees and faster finality for transactions because of the capabilities of f(x)Core.
In short, everything you can do on Ethereum you can do on the f(x)Core EVM with the added benefit of ~2000 tps and low fees. The Ethereum dApps can easily be ported over and are 100% compatible with existing tools such as Metamask / Truffle etc, simplifying it for current Ethereum developers to build on the f(x) Core.
1. ERC20 module: swap between Ethereum network and f(x)Core
Since the previous EVM release in f(x)Core Testnet, developers have been able to deploy smart contracts. However, there has to be a bridge for f(x)Core assets to be converted to ERC20 assets, to enable spending transactions while interacting with EVM. An ERC20 token is a standard for all tokens that live on the Ethereum blockchain. The ERC20 module will record new token pairs, which is the mapping between ERC20 assets’ contract addresses and the corresponding assets in f(x)Core.
In order to register a Token Pair, one has to do the following
a) Initiate a proposal through the governance module
b) Wait for the results of the proposal
c) If passed, the new Token Pair will be registered by the ERC20 module.
As long as the Token Pair is enabled within the module, anyone can convert their ERC20 tokens into its f(x) Core representation token. For example, users can deploy an ERC20 $ETH Token on f(x) Core and create a Token Pair that lets anyone convert their $ETH on f(x) Core into the token representation.
Users will be able to swap assets interchangeably between two entirely different layers: EVM and f(x)Core. This also allows users to bring ERC20 assets into the Function X ecosystem, and vice-versa. With the ERC20 module, users can convert FX into its other ERC20 token pair and use them to buy NFTs, for stacking on DeFi apps and protocols. This opens up endless possibilities.
2. Feemarket Module
The feemarket module has been designed to support Ethereum’s EIP-1559 transaction format in order to make f(x)Core integration simpler for wallets and decentralized applications. This module will define a global transaction fee for the network, and essentially split transaction fees paid into a base fee and tips.
Base fee
The base fee is typically defined at the consensus level and is subsequently burned. It is algorithmically calculated, based on the total gas used in the previous block and gas target.
- it increases when blocks are above the gas target
- it decreases when blocks are below the gas target
Tip
The tip is defined as an incentive paid out to increase the priority of transactions. However in the f(x)Core network, the tip is usually zero, like most chains built on Cosmos, it does not support priority rights. This may lead to gas prices with less volatility and prevents needless delays for users.
3. Migration tool to an EVM compatible 0x address
Before users can start using dApps in the Function X ecosystem, they need to connect to an Ethereum-compatible wallet such as MetaMask. They can then later transfer their f(x)Core assets back to the new EVM-compatible wallet address and spend them within the Ethereum ecosystem.
Reasons for the need of conversion
Currently the process that is used to create the FX address and 0x address on chain are different which results in one private key having two separate ‘accounts’ in the FX address and 0x address respectively, so the funds in the FX address do not correspond with its 0x address.
◦ The old 0x address is not compatible with Metamask, cannot send/perform smart contract transactions, and the signature cannot be verified on the chain.
Conditions for Conversion
◦ Requires an account that does not exist on the chain (address that is tied to a validator node will not work)
◦ Address generated by eth algorithm(eth_secp256k1)
◦ An Address that has not been converted before.
How will the combination be done?
This will need the users to perform “conversion/migration” via their f(x)Core CLI / f(x)Wallet. The team will provide the “conversion tool” in f(x)Core CLI / f(x)Wallet for this to be done.
After the “account conversion” is completed, the user will have:
- an EVM-compatible 0x address, with EVERYTHING in the previous old fx address, such as token assets, delegations, delegating rewards, and proposals, if any.
- a new fx address. What this address holds will be totally the same as that in the EVM-compatible 0x address.
Thank you for reading April Hash Out, we look forward to sharing more exciting updates and progress. If you have any questions or concerns regarding EVM integration in f(x)Core, you can always reach our support team on Function X Forum.
Function X Blog 