Thinking about moving an Ethereum project to EOSIO? Don’t worry, we got you covered! Migrating projects from one blockchain network to another is one of our specialties at Infinite X.
In this article, we’re going to share the top 6 things everyone should know before starting their dApp migration process. In the next paragraphs, you’re going to learn more about:
While this article focuses on migrating Ethereum dApps to EOSIO, everything you’re going to read about EOSIO is still valid if your application is coming from a network different than Ethereum.
When you’re migrating your Ethereum dApp to EOSIO, you can’t skip the EOSIO network resources. The best way to understand them and how they work for your application is with a simple example.
Let’s take a web application deployed on a cloud provider. A web app needs to work with a series of resources that will dictate its performance, the main ones being: bandwidth, CPU, memory, and I/O capacity.
Each time an action is executed, it requires a certain amount of these resources for a specific time. You can estimate how much you’ll need for different case scenarios. A lot of cloud providers like Google Cloud & AWS provides calculators for this. In a case where your resources are not enough to handle the traffic of your web application, you purchase more of the ones you need.
In a very similar way, the EOSIO network resources operate. Each action in your smart contract requires a specific amount of CPU, RAM & NET for its execution. You acquire them by staking EOS tokens (locking them for an amount of time). In a case where your decentralized application doesn’t have enough CPU, RAM, or NET, you stake more EOS tokens to acquire more of what you need.
Note: Unlike CPU & NET, which can be acquired by staking EOS tokens, RAM is a resource that you purchase with EOS tokens.
Both the EOSIO resources and the Ethereum gas fees have their role in the protocol. They both prevent the network from frivolous or malicious computational tasks, such as users spamming the blockchain with an overload of useless transactions. The more complex the operation, the more expensive the fees (the more resources needed).
The difference comes in the way these mechanisms are built. On Ethereum, each user is required to pay the gas fee for his transaction on the application he uses. There is no other option. Unfortunately, this could be a UX killer for the user who doesn't understand how the technology work or if the gas fees are too high (ex: paying $20 in fees for a simple transaction like sending a digital asset).
Users pay a gas fee each time when their transaction changes a state in the blockchain (it's not read-only). They can't collect the fees back.
On EOSIO, instead of a transaction fee, resources like CPU and NET are used. Sometimes, people describe the resources as the equivalent of the gas fees in Ethereum. That is not entirely accurate.
The EOSIO resources, like CPU & NET, act like a battery that regenerate after an elapsed time. Users who are "paying" for these resources are doing it only once. They can use the same resources over and over again for multiple transactions.
EOSIO also allows developers to take care of all of the user's resources. This option enables them to provide a better user experience, similar to what a user would expect from a non-blockchain app.
Unlike Ethereum, EOSIO enables developers to create hierarchical permissions structures out of the box. That allows the creation of complex authorizations for different operations inside your smart contracts.
For example, let’s say an online media is using a smart contract for its blog publishing process. The smart contract could have four actions: create, edit, review, and publish. Each of them, through a permission structure, can be connected to an account (user) within the online media organization. That provides greater security enabling only authorized members to execute these actions.
In the same way, users outside the organization (third-party providers) can receive some level of permission.
By default, on Ethereum, smart contracts are non-upgradable. Once they are created and deployed on the blockchain, developers can't change their code. However, the practice showed that such type of smart contract behavior is not entirely beneficial for companies.
Out of necessity, the upgradeable ethereum smart contracts were born. A solution that enables developers to update existing contracts. Either for fixing security issues or for adding new features.
On EOSIO, developers can update their smart contracts by default. However, a smart contract can also become non-upgradable, just like in Ethereum. Thanks to the EOSIO permission structures, developers can turn the permission of the deployed contract over to the eosio genesis account. That locks the smart contract making any updates impossible without the 15/21 block producers' approval.
The most affected part of the dApp migration process is the business model. That's happening because, more than often, business models have a strong connection with the developed solution.
In turn, the solution is dependent on the technical limitations and possibilities of the blockchain protocol.
Because different protocols have different specs and needs, this can directly reflect on the business model itself. In some cases, the superior protocol will benefit the model by making it better. In others, it may require the model to be further optimized or to be changed completely.
Thanks to EOSIO EVM, it's possible for Ethereum smart contracts, written in Solidity, to be executed on EOSIO.
The contract duplicates the functionality of the Ethereum Virtual Machine while allowing the Ethereum contracts to leverage the benefits of EOSIO, such as increased transaction throughput and faster smart contract processing.
That feature of the protocol opens a new world of possibilities for Ethereum projects.
Moving an Ethereum project to EOSIO might feel like an overwhelming task both for developers and business owners. That’s especially true when the application is in a later stage of development or it’s in production.
We always suggest such type of dApp blockchain migrations to be managed by a team experienced in both protocols. They can easily spot any potential migration issues at the beginning which will allow for smoother migration after.
If you still have questions in mind regarding the dApp blockchain migration? Reach to our team here.
Are you looking to start developing on EOS blockchain and become an EOS developer? This guide was created for newbies and it will help you make your first steps in EOS blockchain development before moving to more advanced programming later in the series.
The best blockchain learning resources for non-techies. All you need to understand how blockchain technology works
Take a short quiz to find out whether this technology can be applied to your organization.
