Fusion PSN Technical Update 2.0
After the successful launch of PSN 1.0, the technical team has been focused on improving the overall performance of the network. The community has played an important role in this process, helping to test the network, identify issues and even propose some resolutions. Fusion would like to extend our appreciation for the community’s assistance and dedication.
The tech team is super excited about the innovative functions that are currently running smoothly on PSN 1.0, including time-lock, create asset, USAN and more. The team is also pumped to release the Quantum Swap interface and asset gateway (that enables lock-in/lock-out of ERC-20 tokens) in the very near future.
With the release of PSN 2.0 on the horizon, we want to elucidate some of the network improvements that the technical team has been working diligently on.
- Network Communications
To avoid network communication conflict with the existing Ethereum implementations we have changed our network to operate on Network ID 55, ChainID 99551, and discovery port 40403 and 40401. The nodes we are currently testing in the lab are synching almost instantly because of the changes.
2. Getting Rid of the Dreaded Merkle Root.
An invalid merkle root occurs when the hash of a block received is different to the hash that has been calculated locally. In our api functions we had certain fields that were dependent on time. The field was using the local computer’s time vs the block time which would be the same for all computers. This one slight difference causes the block’s hash to be calculated differently and consequently the block is rejected. All api functions within the Fusion ecosystem have been reviewed to ensure consistency across nodes.
3. Improved Error Reporting
Fusion supports powerful features for the management of assets, value over time, and quantum swapping. The api functions which can be found in the github project web3-fusion-extend call the fusion engine. The fusion engine has been updated to include rich error logging both for the block explorer and the gateway console to understand why a function has failed to be submitted. This will allow application developers to quickly correct their code and deliver solutions fasters.
4. Consensus Engine and Proper State
Fusion’s consensus engine relies on the fact that all previous state information is present when deciding which ticket is valid. This requires all our nodes to be full archival nodes. We appreciate this might not be ideal for all situations because of space issues and are reviewing for the next version a different approach. The upside is that the fusion nodes are syncing well, and ticket selection is securely replicated across the network. We will have more info on this as we make improvements to the network.
For those more technically minded, Fusion uses Proof of Stake as its consensus engine. Tickets are contained in the state of the block. To ensure tickets are selected in the right order across the Fusion blockchain, Fusion must receive the ticket array and process sequentially to insure the owner of the ticket has mined the blocked. If the miner is not available then another ticket is selected. Fusion’s PoS engine needs the ticket information from each block to proceed accordingly. The ticket information is currently recorded in the state of the block. When the Fusion chain rebuilds itself, it cannot currently support fast synching; as it will need all state information from each block to recreate the ticket life and allow syncing of older blocks. We are currently looking at the best approach with regards to securely storing ticket information in order to mitigate the requirement of being a full archival mode. For now on PSN 2.0 all nodes will need to be fully synced archival modes in order to participate.
