For some apps that will use Pocket, it may be important to allow Service Nodes (SN) to support older wallet versions of a Blockchain.
For example: If a new wallet version comes out that has a core change, like changing RPC calls, their app would crash if their API requests are routed to Service Nodes that are only supporting that newest wallet.
Therefore, it may be valuable for some SNs to support older wallets of blockchains. SNs could choose which wallet versions they want to support. By default, all calls should be dispatched to SNs with the newest wallet version, but any developers that specify a specific wallet version should be routed to the appropriate SN.
This is a possible workflow for how the network handles wallet versioning
- New Ethereum Wallet v12 is released to Github
- Dispatcher Nodes start a 1 day count down for SN to update their wallets, and still route calls to v11 wallets.
- After 1 day, only SNs with v12 wallets will receive all default Ethereum calls, thus incentivizing the majority of SN to support the latest wallet to get rewards.
- Any apps that specify v11 wallets in their call can be routed to SNs with v11. Some SNs may find it valuable to run older wallets for some applications.
This kind of workflow incentivizes every SN to update to the new wallet within a day, while also allowing SNs to keep servicing older wallets that some apps may require.
This also allows devs to specify a particular wallet to ensure their app doesn’t crash when a new update is released. Regardless if updating their app takes a few days or months, as long as there are SNs willing to run older wallets, they can make jumps to newer wallets in their own timing. Devs building with Pocket don’t have to be forced into being compatible with the newest wallets immediately.