Option 1: Deploy and Use a New Contract
Sub-option 1.1: Complete Abandonment of the Old Contract
At the first specified block number, disable all transactions in the old contract in Golang and inform all nodes to suspend transactions.
Import all data from the old contract into the new contract, ensuring functionality and data correctness.
At the second specified block number, switch MasternodeVotingSMC to the new contract in Golang.
Test the new contract thoroughly; if no issues arise, notify all nodes of a successful upgrade to use the new contract.
Sub-option 1.2: Permanent Coexistence of Old and New Contracts
Disable specific functions in the old contract in Golang, such as uploadKYC, propose, and vote.
Switch MasternodeVotingSMC to the new contract in Golang.
Notify all nodes to use the functions of the new contract.
The new contract reads asset data from the old contract but not other data, handling both the new and old contract's validatorsState data structures.
The old contract only allows withdrawals.
Sub-option 1.3: Temporary Coexistence of Old and New Contracts
Before a specified block number:
The new contract reads asset data from the old contract but not other data, handling both the new and old contract's validatorsState data structures.
In Golang, the old contract only allows withdrawals, disabling other functions.
Switch MasternodeVotingSMC to the new contract in Golang.
Notify all nodes to use the functions of the new contract.
Notify all nodes to withdraw from the old contract.
After the specified block number:
The new contract no longer reads asset data from the old contract.
Disable all transactions in the old contract in Golang.
Option 2: In-place Upgrade of Contract Code
Write tests for the new contract.
Backup the code of the old contract.
Extract the code of the new contract.
Modify Golang code to replace the contract's code at a specified block.
Notify everyone of changes in contract functionality.
For more details, refer to: XDCValidator Upgrade Discussion.
Discussion (4)
we are going to try to use option 2 to test first , and move discussion to github.com/XinFinOrg/XDPoSChain/di...
how do the all above mentioned scenarios manage the current XDC tokens that are held by XDCValidator smart contract?
The amount is around 3,330,826,898 XDC ~ $134,565,406
Which acts as the native(solo) staking on the xDPOS protocol.
explorer.xinfin.network/address/xd...
Option 1 The assets will remain in both the old contract and the new contract. As a dapp project, you need to withdraw the assets from the old contract first, then change the validator address to the new contract, and call the new contract later
Option 2 The asset remains in the contract, As a dapp project, no need to do anything
I feel option 2 is a better solution. we should have a safe migration plan for new updates, Security-first approach might help in this case as XDCValidator contract is one of most important SCs on XDC Network.
Many projects may depend on XDCValidator SC as a source to verify MasterNodes and pull some data, the upgrade should be backward-compatible regarding storage slots and its SC address.