FUSION 3.6 Mainnet Upgrade

Time-Locks in smart contracts, EVM updates, and better APIs.

Great news Fusionites! The Fusion Mainnet 3.6 upgrade has been scheduled for block height 1,818,300, expected to occur on Tuesday, March 31, 2020 (Shanghai time).

The upgrade introduces multiple improvements and bug fixes. The highlights:

1. Support for both Time-Lock and Fusion assets in smart contracts
2. Expanded EVM instructions set (including SHL and SHR)
3. Upgrades to existing APIs to increase the usability of Fusion’s technology.

Due to the major updates introduced, this upgrade is a hard fork which renders the previous software version incompatible.

Validator nodes are required to update their node software in order to continue validating blocks.

Should any operator fail to update their node before the block height of the hard fork they will not be able to validate blocks and will run the risk of having tickets retreated until they do.

What’s Included in 3.6 Upgrade?

Protocol Changes in Version 3.6:

1. FIP-001: Added smart contract support for Time-Lock and Fusion Assets. Smart contracts now support sending and receiving any assets including FSN, with or without Time-Lock. Head over to our Github FIP for instructions and samples, then build your automated Time-Lock Dapp.
2. Added support for new EVM instructions (e.g. SHL, SHR)
3. Proof-of-Stake (PoS) hash calculation upgraded to version V3: total ticket hash is no longer involved in the calculation.
4. Fix for the issue where ticket purchase transactions were delayed for an extended period of time.
5. Improved opSuicide operation in smart contracts, including transfer of asset balance and TimeLock balance.
6. Testnet Network ID modified to match its Chain ID.
7. Updated QuickNodeSetup node docker upgrade script.
8. Stop transaction pool from accepting Time-Lock transfer transactions with empty receiving addresses.
9. Enhanced detection of start and end times for ticket transactions.

API Changes in Version 3.6:

All original APIs remain compatible. The following additions has been made to the API based to better support developer needs:

1. fsn.getLatestNotation — Get the latest short account address.
2. fsn.getTimeLockValueByInterval — Get the Time-Lock balances filtered by time interval.
3. fsntx.sendTimeLock — Used in conjunction with TimeLock and Asset to perform smart transfer.
4. fsn.getAddressByNotation — Getting a destroyed short address (USAN) is reported directly instead of returning an empty address.

How does this upgrade affect me?

I hold FSN tokens. What do I need to do?

Regardless if you are holding FSN (native, ERC-20 or BEP-2) in an exchange, web wallet or hardware wallet, this upgrade will not require you to do anything.

Note: if you are contacted by 3rd party exchanges or wallets regarding this upgrade, please follow them directly for instructions as they may have their own instructions.

I am running a node. How do I upgrade?

Option 1 — Use the QuickNodeSetup script

Fusion’s QuickNodeSetup script offers an easy one-click option to upgrade your node to version 3.6 without deleting chain data or affecting mining. This is the recommended approach.

1. Execute the following command to run QuickNodeSetup and access the node management menu:

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

Note: You may have to replace the quotation marks in your terminal with “straight quotations” as Medium seems to be formatting the marks into curly quotation marks.

2. Select option “2. Update node” to update to version 3.6 in one click. Please perform the update while the node is active to avoid losing tickets.

For more detailed instructions on how to run the QuickNodeSetup script, please refer to efsn Github repository and node setup guides.

Option 2 — manually deploy the docker image

1. Re-run the docker container creation command.
2. For details, please refer to efsn Github repository.

Option 3 — Compile and deploy from source code

1. Enter the efsn directory.
2. Obtain the master branch version 3.6 efsn code using:
   git pull
3. Compile the efsn application using:
   make efsn
4. Restart efsn.

I am running a node. What will happen if I fail to update?

If you fail to update your node software before the hard fork at stated blockheight, your node will continue to validate blocks using the older consensus rules and will only be able to successfully synchronize to any other node that also failed to update in time. As a result, any node running the older software after the hard fork will not be able to validate blocks after the hard fork and active tickets will be lost.

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

If you are using efsn client and API services, such as RPC API or SDK, please pay attention to the changes this update brings, then update and test your application on the test network.

Disclaimer:

• Update date is estimated based on average block times as of writing.
• This is an emerging, evolving and highly technical field. If you choose to implement the recommendations in this article and continue to participate, please ensure that you fully understand the implications of these recommendations for you. You should understand the risks, including but not limited to unexpected code bugs. When choosing a recommendation, evaluate the risk of the results independently. This article and the recommendations therein are by no means a sales agreement, and in no way constitute a guarantee clause in any sense, including but not limited to the guarantee of the FUSION network and efsn client mentioned in the text.