Feature : Pinning as a service and Recover Token [Tokenchain]

[Allen-Cherian]

The pinning service allows token owners to pin their tokens on a pinning node on their behalf. The token's ownership remains unchanged; the pinning node will have all the information about the pinned token and token chain. The recover token feature allows us to retrieve the token and tokenchain from the pinning node.

Commands added :

1. pinrbt : The command to initiate a pinning transfer to the pinning node from a sender node. Eg: ./rubixgoplatform pinToken -port 20013 -senderAddr bafybmibw7lvjidvlohhdsdshbj4bcly7y6zwanlwcloj5puaizzstyfbhi -pinningAddress bafybmihs3hniinkuk3nh2bo4geyljevyjjyixtnrn3tdqe3yecqrzv22qq -rbtAmount 1 -transComment "Test Pinning As a service " -transType 2
2. recovertoken : The command to retrieve the token and tokenchain from the pinned node. Eg:./rubixgoplatform recoverToken -port 20015 -senderAddr bafybmibw7lvjidvlohhdsdshbj4bcly7y6zwanlwcloj5puaizzstyfbhi -pinningAddress bafybmihs3hniinkuk3nh2bo4geyljevyjjyixtnrn3tdqe3yecqrzv22qq

APIs added :

1. /api/initiate-pin-token Request Structure :

{
    "pinningNode": "bafybmiavcsudhxw4ecj2yduqms5nioekbts7ovowtldcrprstwnnkhu7ua",
    "sender": "bafybmiec5fxospbacox536gcybwpqlu7nnqvtto32ud3pjp5eaojf76lxi",
    "tokenCOunt": 3,
    "comment": "Pinning Test Latest",
    "type": 2
}

2. /api/recover-token Request Structure :

{
   "pinningNode": "bafybmidpuc3vcegwxjrr6xnvvwvt3txmhkjnvdgb2kbyvemilw4lptxlvm",
   "sender":"bafybmid23tc2ddfsmxbb5h26cyiljkylbp7fjsgpbucxlm43vzbm5p2b7y"
}

Test Results :

1. Successfully pinned a token when the balance was 1.
2. Transferred the pinned token to a different receiver from the sender node :
   • The status in the sender node changed to 4 (TokenisTransferred)
   • In the pining node the status is still 15 (TokenIsPinnedAsService)
3. Transfer from the pinning service node failed:
   • The error is insufficient balance, the reason is that, when we fetch the balance from the db, we are searching the token table with the did value, in the tokentable of the pinned node, the did value will be of the sender node, basically the owner node. Also even if that is changed in that particular part, in the latest tokenchain block when the ownership is checked the tokenownership check will fail and the pinning node won’t be able to transfer this token.
4. Previously transferred token in the pinning node's database was recovered but failed to transfer:
   • When an already transferred token which was existing in the pinning nodes db was recovered and transferred, the transaction didn’t go through. Consensus failed and the tokenstatus in the recovered node’s db was changed to 12(Tokenchainsyncissue). Basically the node was not able to sync the tokenchain. In the quorum part the log showed the tokenstate was already pinned.
5. Pinning of part token successful. A whole token in the sender node was split and was able to pin the token on a pinning service node.
6. Recovery of Part Token successful.
7. Transfer of all the recovered token were successful.

[gklps]

Suggestion for Enhanced Flexibility:

To improve the generalizability and future-proofing of the command interface, consider the following changes:

Command Renaming:
    ./rubixgoplatform pinrbt --> ./rubixgoplatform pinToken
    ./rubixgoplatform recovertokens --> ./rubixgoplatform recoverToken
API Endpoint Updates:
    /api/initiate-pin-rbt --> /api/initiate-pin-token
    /api/recover-rbt --> /api/recover-token

This approach makes the commands and endpoints less tied to a specific token type ("rbt"), allowing for easier adaptation for other token types that are introduced later.