Fusion MainNet 3.2 Upgrade Announcement – FUSION Foundation

At block height 739,500 on Fusion MainNet scheduled to arrive on October 20, 2019 (Shanghai time), Fusion will activate a network upgrade.

The network upgrade serves a number of purposes:

Executes on the ‘state change’ voted by the community as the preferred remediation solution to recover funds following the Fusion wallet theft.
Introduces new run parameter option –resyncfrom which enables users to resynchronize chain data from a specified block height.
Implements upgrade of version 3.1 to MainNet that was introduced to TestNet on September 29.

As preparation for the scheduled ‘state change’, all transactions on the Fusion network except ‘buy.ticket’ transactions will be restricted between block height 739,500 and 786,000. At block height 786,000, the remaining FSN tokens in the thief’s wallet will be returned to the Foundation, and all transactions will be re-enabled.

Block height 786,000 is likely to arrive on October 27, 2019 (Shanghai time) based on average block times but may fluctuate by 1 day in either direction.

What does this upgrade involve?

The network upgrade is a hard fork, meaning all nodes will have to transition to the new chain to continue participating in the network. The changes and improvements captured in this upgrade necessitate that the verification node needs to be updated, hence the hard fork.

Nodes that do not support the upgrade after block height 739,500, will no longer validate transactions on the Fusion MainNet.

How does the upgrade impact me?

Whether you are holding native FSN, ERC20 FSN or BEP2 FSN, the planned upgrade will not impact you, you do not need to do anything. If you are running a staking node / full node on the Fusion MainNet, then please upgrade to the latest version 3.2.0 by following the instructions below.

IMPORTANT NOTE:
For projects/organizations/developers/exchanges that have built programs/applications on Fusion’s MainNet, you will need to support the hard fork for your project/application to continue functioning correctly.

What are the steps to execute the upgrade?

Fusion’s QuickNodeSetup script allows stakers to update their nodes to the latest version without having to delete chain data. This means you can support the upgrade to version 3.2 with almost zero downtime.

Option 1 — If you set up your node using the ‘QuickNodeSetup’ automated script:

Navigate to the main menu of QuickNodeSetup using the following command:

bash -c “$(curl -fsSL https://raw.githubusercontent.com/FUSIONFoundation/efsn/master/QuickNodeSetup/fsnNode.sh)”

For further details on how to run the QuickNodeSetup script and access the screen above please refer to the Fusion efsn Github repository or node setup guides.

2. Enter choice 2 to update your node to the latest version. You may enter this option on live staking nodes in order to avoid losing tickets. Entering any other number may cause your node to stop and may result in loss of tickets.

Option 2 — If you manually setup the Docker image:

Rerun the same Docker command used to initialize the Docker container.
Please refer to efsn Github repository for further details.

Option 3 — If you are building from source:

Stop your node and navigate to your current efsn directory
Pull the latest code from the efsn repository

git pull

3. Build the application

make efsn

4. Restart your node.

What happens if I do not upgrade my node to the new version of MainNet?

If you do not update your node to the latest version after the upgrade is executed, your client will use the pre-fork consensus rules to synchronize with other nodes that have also not supported the upgrade. Since the consensus rules have changed and are not compatible with each other, nodes that do not update will not be able to earn rewards or send transactions on the updated Fusion MainNet.

What happens to my staking node between blocks 739,500 and 786,000?

All transactions except for the purchase of tickets have been disable between blocks 739,500 and 786,000. Staking is not affected, you can continue to purchase staking tickets and participating in the network. Do not send any other transactions of the network during this period.

What should I do as a service provider such as an exchange, mining pool or wallet application?

If you are using an efsn client or API services, such as an RPC, API or SDK, please be aware of the changes brought by the upgrade. All applications can be tested on Fusion’s TestNet in the lead up to the MainNet upgrade. This gives you the opportunity to test that everything is functioning correctly before the upgrade and ensure that there is no down time.

What exactly is included in this upgrade?

The following updates are included in MainNet upgrade 3.2:

Executes on the ‘state change’ voted by the community as the preferred remediation solution to recover funds following the Fusion wallet theft.
Introduces new run parameter option –resyncfrom which enables users to resynchronize chain data from a specified block height.
Implements upgrade version 3.1 that was introduced to TestNet on September 29.

Remind me what was included on version 3.1 that was introduced to TestNet on the 29th of September?

1. Check the SnapData data in the block header in the consensus.

2. Upgraded support for private swaps in the consensus.

3. Increase reporting and introduction of punishment mechanisms for ‘Double Blocking’.

4. Update PoS hash calculation method to V2 version.

5. Support transfer of short account numbers (USANs) through Fusion wallet interface.

6. Startup node will only start to buy tickets automatically after syncing to the latest block height.

7. Add interface fsn.getStakeInfo to get staking statistics.

What changes will be made to the APIs after the upgrade to MainNet version 3.2?

1. Add fsn.getTransactionAndReceipt to decode the input additional data of the transaction and the data data of the transaction receipt.

2. Modify debug.dumpBlock and export time-lock balance

3. Move startAutoBuyTicket and stopAutoBuyTicket from the fsn module to the miner module.

4. Includes API updates that were included in version 3.1 that was introduced to TestNet on September 29.

Remind me what changes were made to the APIs on version 3.1 that was introduced to TestNet on the 29th of September?

A. All original API functions from the previous version (version currently running on Fusion MainNet) remain compatible.

B. Additional API functions were included to enable and disable autobuy ticket purchase and getting staking statistics.

1. fsnbt.isAutoBuyTicket
2. fsnbt.startAutoBuyTicket
3. fsnbt.stopAutoBuyTicket
4. fsn.getStakeInfo

C. The following API functions were modified to include an additional optional paramater ‘toUSAN’ that support the transfer of Short Account Numbers (USANs).

SendAsset
assetToTimeLock
timeLockToAsset
timeLockToTimeLock

Contact information
– Fusion Telegram Channel
– Zendesk support

Disclaimer
This is emerging, experimental and highly complex technology. If you choose to implement the recommendations in this article and continue to participate, please ensure that you have fully understood the impact of these recommendations on you. You should understand the risks involved in using experimental technology, including but not limited to unexpected code bugs. When executing on recommendations, please independently assess the risk of the results. This document and the recommendations therein are in no way a sales agreement and do not constitute a warranty in any sense, including but not limited to the warranties mentioned in the text for the Fusion network and the efsn client.

Published at Fri, 18 Oct 2019 00:15:24 +0000

{flickr|100|campaign}