ICON 2.0 Migration Plan

Delegate / Validator Candidates Node Operation
1

Hello everyone,

ICON 2.0 is approaching, and we are currently preparing the network migration process. To make this as smooth as possible, effective communication is essential.

Currently, the main communication channel between the ICON Foundation and node operators is the ICON P-Rep MainNet telegram channel. If you are already in this channel, please make sure you can receive notifications. If you are a P-Rep and you are not in this channel, please contact me on telegram @nymkappa and I will add you in there.

The network migration process is still being drafted by engineers and it is close to completion. We will run internal test in order to identify major issues in the coming weeks.

The migration plan will be shared with the community in a transparent manner, and we will release updates in real time during the migration.

Requirements for P-Reps participating in the migration

  • ICON1 - LOOPCHAIN node
    • Running LOOPCHAIN to follow the current ICON1 blocks
  • ICON2 - goloop node
    • SSD near 2TB+ ( 300GB for LOOPCHAIN data, 1.1T+ for ICON2 data )
    • CPU with 8 Cores (the more the better)
    • 16G RAM (the more the better)
    • Network
      • Connection to LOOPCHAIN RPC Server
      • Internet connection
      • Accessible P2P (TCP) ports

Note that not all P-Reps are required to run the migration process. If you are interested in running the migration process, please let us know on Telegram.

If you are not a technical user or do not want to do the migration manually, blockchain snapshots for ICON 2.0 will be available for download.

Network interruption during the migration process

During the network migration process, the network should be paused. We expect this interruption in network operation to last for a couple of hours, but could last longer in case there are unexpected issues during the process. We would like smart contract operator to assess related risks linked to such pause in the network and prepare accordingly. If you have any concerns about this, please let us know as soon as possible.

We will keep updating this thread to share more details about the migration process. Make sure to monitor the forum and telegram channels in the mean time.

Thank you.

7 Likes
2

Hey Nym
so with the network interruption i assume this means all the dapps wont be responsive for that timeframe?
If so have we got a game plan for our defi protocols? If there are any sudden movements in price balanced user could be impacted.

Thanks

3

Yes that’s something we are discussing. There is nothing we can do technically to avoid network interruption so we will do everything we can to raise awareness around this issue, and of course we will try our best to reduce this downtime with P-Reps.

So yes, once P-Reps start migrating, no transactions will be processed until ICON2 is up.

Each application will be responsible for assessing risks and communicating them to their user base. In the case of defi protocols, users should prepare accordingly yes, by posting more collateral for a couple of days, or paying back their loans until ICON 2.0 is running.

We also have some contingency plans ready that P-Reps will be able to follow in case they cannot start ICON2 network properly.

We will test different network migration scenarios in the coming weeks as well.

2 Likes
4

can you please share here resources for deploying ICON 2.0 nodes and general recommendations or things to take into account in preparation for the migration so that all P-Reps can read.

thanks.

1 Like
5

You can find some ressources for goloop here Get Started - ICON DevPortal. To get comfortable using it I would suggest you try to join Sejong testnet.

I will share a detailed network migration plan soon.

6

Here is a more detailed plan for the network migration.

Stage 1

Expected duration 2~3 weeks

In this first stage, a selected subset of nodes will migrate ICON1 blocks (starting from genesis) using the block import tool. If you are interested in participating in this process, please let me know. This subset will be composed of some P-Reps and citizen nodes operators. It is not required to have everyone participate in this (less than 10). It will be required to have high end processing power in order to import legacy blocks as fast as possible.

We will also prepare backup and seed nodes during this first stage.

Stage 2

Expected duration ~2 days

In this second stage, all P-Reps will get ready for ICON2. They will download the new node and the backup data generated in stage 1. Once all P-Reps catch up with the tip of the chain, we will effectively have two chains running (ICON1 incoming blocks will be converted to ICON2 format in real time by all P-Reps).

Stage 3

Expected duration 1~2 days

In this third stage, it will not be possible to send transactions to P-Reps. Connections to ctz.solidwallet.io will be temporarily closed. Once again we want to insist on this. It will not be possible to execute any transaction during this stage, so please prepare accordingly.

Through a revision proposal vote, ICON1 consensus will stop at a predefined block height, which will be defined later. Once all P-Reps have reached this block height, they will start ICON2 consensus. If everything goes as planned, ICON2 will be officially running its MainNet!

ICON2 database backups will then be prepared, citizen nodes will be restored using those backups and ctz.solidwallet.io will be reopened.

At this point, the network migration will be completed.

Note: If for unexpected reasons P-Reps are not able to reach consensus on ICON2, a contingency plan is ready and P-Reps will be able to resume ICON1 consensus.

A step by step guide will be provided for nodes operator before the network migration. Please make sure to follow the Foundation twitter account to stay up to date.

5 Likes
7

I agree. I hope we have some good documentation here. There are some good discussions going on in the Prep Chat on Telegram, but not nearly enough.

It would be ideal to slow down here, and to have well presented and well thought out directions for everyone because even though it seems like we are close, it doesn’t feel that way. When my peers are worried about having larger overhead with less rewards and not being able to pay the bills that worries me and should worry everyone.

Most of these guys have been running nodes since Icon began.

As has been stated, the IISS can be adjusted and we have a period to work for our bonds so that would be nice to spell out for us as well.

I feel as if this is the most important moment for all of us and the Icon Network is the only reason I am writing.

Sub P-reps need to know what they need in the form of specs that are attainable and affordable. We are not just a localized network and need to retain our fellow network operators in my opinion. They’ve been there for us and we’ve been there for them for most of the history of Icon.

As a truly decentralized network we need them.

This is the time to do this correctly, and I hope that we have great documentation and specs going forward. I hope the rewards are adjusted so Preps feel comfortable migrating.

It seems like we will all need at least 2TB and better throughput machines which isn’t a problem unless a hard working sub rep can’t afford one.

Thanks for listening to our concerns.

3 Likes
8

We’re definitely going to share much more technical details in the coming days. We want this migration to be a successful event as much as you do :slight_smile: . And you will have time to prepare. There is no point in rushing it.

We heard concerns about profitability of small P-Reps. This is my personal opinion, but there will be some who won’t be able to keep up with other P-Reps, but there will also be new candidates. It is true for any network where block producers competes with each other, regardless of the consensus mechanism. Is it an integral part of the security model for any network, specially proof of stake ones.

We provided an initial IISS 3.1 Model here https://forum2.icon.community/t/iiss-3-1-model-for-icon2/2237. Ultimately the profitability of P-Reps is defined by P-Reps themself through network proposal. We just set some initial value because there need to be some when IISS 3.1 goes live, but at the end we have no say in what P-Reps think is best for the network.

Please review it and give your feedback on this matter in the dedicated post https://forum2.icon.community/t/iiss-3-1-model-for-icon2/2237.

Thank you for sharing your concerns. It’s very helpful and I hope it can start some discussions between P-Reps regarding IISS 3.1 and ICON 2.

9

So we can assume that stage 3 can be upto 1 epoch time, where the P-Reps will vote on the proposal and if the proposal passes, ICON 2 starts. If proposal fails, ICON 1 will resume.

So DApps can assume no transactions for 1 epoch from users ?

10

I’m not sure what you mean by epoch.

In the best case scenario, where P-Reps all cast their vote in a very short amount of time, the “downtime” will be short (minutes). But in case votes are slow to come in, or there are sync issue while starting ICON 2 revision, it may take a couple of hours.