Layer 2 Migration: Phased Approach

In this short action-oriented post we look at the phased approach to Layer 2 migration.

Building a decentralized application is not necessarily hard as it shares 90% of the same attributes as a traditional application. The differences, though, are unique. These differences include transaction costs (in the form of gas fees) and transaction commit times which can introduce significant latency to a decentralized application.

Both issues can be solved, or at least extremely mitigated, via the use of elastic sidechains. A sidechain is a Layer 2 component that connects with a main blockchain network, most often a public one such as the Ethereum mainnet. A sidechain adopts the same underlying philosophy in terms of preservation of transactions via a chain of transaction blocks but it may use a different consensus algorithm and/or validation method. It also may contain additional features such as additional storage options, permissioned access, zero knowledge proofs, and more.

Other materials discuss how to get started with an elastic sidechain. This post will talk about the development process and how migrating to a sidechain is often performed using a phased approach. This approach greatly reduces risk and makes the process much easier.

Phase 1 - A Single Smart Contract

Our experience with applications currently live on the Ethereum mainnet is that the developers first want to try out something that would have little impact if something went wrong. Their Phase 1 then is typically moving a single smart contract to an elastic sidechain. It is an easy choice in that it’s a single computational process. It also has a direct benefit in that such a move will typically reduce gas costs a fraction if not zero them out altogether.

Such a move is also more readily recoverable in that if something goes awry, then they can just switch it back to Ethereum and continue incurring gas costs. Moving a single contract first allows developers to take as much risk or as little risk as they would like when integrating a new technology.

Decentralized app developers who have apps already live on Ethereum and have traction and users, are understandably more risk averse. They want to move things over slowly instead of all at once. Developers who have yet to release their dApp can build with SKALE from the beginning. Developers who are live, though, tend to use a phased approach when moving to elastic sidechains.

What we see with dApps that are live and have traction is that they're trying to go to the next phase of their development and that is speeding it up. Using any new solution, regardless of what it is, introduces risk because of what your end users might experience. A phased approach allows them to migrate certain transactions at a controlled and monitored pace in a way that can be rolled back if needed.

Although it’s tempting to want to borrow from the AB testing world where a developer might want to migrate 10% of traffic, 50% of traffic, and so forth, most developers are just going to do a full cut-over of a single contract. This one piece of their dApp that can be moved to SKALE, live there, and then see how it works. The rest of the smart contracts will still live on Ethereum, which is completely fine.

The reason again for the move to an elastic sidechain is because of the reduced gas cost and because transactions will go faster. The latter means end users won't have to wait for transactions to complete which means happier customers. (Lower latency almost always translates into a better user experience.)

Phase 2 - Additional Smart Contracts

After getting a single smart contract moved to an elastic sidechain, the next step is to move other smart contracts to the same sidechain or to a new sidechain. The flexibility of SKALE elastic sidechains means that multiple sidechains can be employed – much like using multiple service meshes or even different databases. The use of sidechains allows the freedom to architect a decentralized application by separating concerns, logic functions, or optimizing performance or storage flows. This issue is discussed more at length in our post on Moving Away From a Monolithic Mindset.

Moving smart contracts one by one lets developers choose the contracts that will have the most impact in terms of cost benefits or performance gains and then watch the performance to make sure they are operating correctly. Any mal-performing contracts can be rolled back to the mainnet if needed. Migrating smart contracts one by one is similar to how a developer might approach going from a monolithic app to a number of microservices or serverless functions. Pick the ones with the largest benefits or least risk (or combination thereof), move them to the new platform, and make sure they are performing to spec.

Phase 3 - Interchain Messaging

After testing out the smart contract moves, developers will then typically want to test out interchain messaging. They don't necessarily want to deal with currency or token transfer right away, however. They want to be able to transfer back and forth messages. Just the low-level messaging pieces and state changes. This event happened and here is the outcome. Developers will then send this outcome back to Ethereum and have the smart contract on Ethereum perform the pays out or token transfers.

In other words, developers will execute simple but critically important contracts and state changes on Ethereum and use elastic sidechains to execute more complicated contracts and ephemeral transactions and state chains. This approach allows them to develop much faster on a subchain at less cost and with much lower latency. Using the mainnet as the exclusive chain for all transactions will not be practical for any application of significant throughput or complexity because of cost and latency issues. This is likely to be the case no matter what happens with throughputs and capacities of public mainnets.

Summary

Elastic sidechains have long been seen as an essential component in the blockchain stack. This realization has become even stronger as dApps have progressed in complexity and design. The question for many dApp developers is no longer why Layer 2 but how Layer 2. And in this regard, there are two immediate recommendations. One is to migrate using a phased approach – moving a single contract at the start, one that can benefit from lower gas costs and increased throughput. Additional steps then include moving additional contracts as well as making use of interchain messaging.

The other recommendation is to consider using multiple sidechains, not unlike using sets of microservices or serverless functions in traditional cloud applications. This topic is explored in depth in another post. But for now, taking sidechains one step at a time and considering a phased approach is a solid recommendation – one that has been tried and passed along by more than a few reputable dApp developers.

------------------------------------

About the SKALE Network

SKALE Labs is the creator of the SKALE Network, an elastic blockchain network protocol. The mission is to make it quick and easy to set up a cost-effective, high-performance sidechain that runs full-state smart contracts. SKALE Labs aims to deliver a performant experience to developers that offers speed and functionality without giving up security or decentralization. You can follow SKALE Labs on Telegram, Twitter and Discord, visit the SKALE website, and check out our Developer Documentation.

Disclaimer — This document is for informational purposes only and does not constitute an offer or solicitation to sell shares or securities in the N.O.D.E. Foundation, SKALE Labs, Inc. or any related or associated company. Any such offer or solicitation would only be made by a confidential offering memorandum and in accordance with applicable securities and other laws.