[ABR] Refactor xamdata Handling in transition-dapp to Support Assets Transfers and Generic Custom Instructions (Beyond SEKAI)

[kmlbgn]

Description

sekai/x/layer2/client/cli/tx.go

Lines 521 to 531 in 1a5be2f

	Use: "transition-dapp [dapp-name] [status-hash] [version]",
	Short: "Send dapp transition message",
	Args: cobra.MinimumNArgs(3),
	RunE: func(cmd *cobra.Command, args []string) error {
	clientCtx, err := client.GetClientTxContext(cmd)
	if err != nil {
	return err
	}
	msg := types.NewMsgTransitionDappTx(
	clientCtx.GetFromAddress().String(), args[0], args[1], args[2], []sdk.Msg{},

transition-dapp currently expects a fourth parameter of type []sdk.Msg{}, which supposedly refers to xamdata.
xamdata is meant to allow applications to bundle xam messages (containing arbitrary instructions for inter-app communication and assets transfers such as settling internal users balances). However, the expectation of a sdk.Msg type suggests that transition-dapp expects only transactions destined to SEKAI, which is incorrect.

Expected Behaviour

• The xamdata sent by applications should resemble the structure of the transaction created by the transfer-dapp, but should be capable of containing an array of such transactions, allowing multiple REQUEST operations to be packed together. xamdata must carry asset transfers AND custom instructions.

• The xamdata must allow RESPONSE type to be appended. It should be the only way for applications to respond to XAM REQUEST, hence AckTransferDappTx need to be refactored/deleted since the ABR should process xamdata.
  

  sekai/x/layer2/keeper/msg_server.go

  Line 553 in 1a5be2f

  func (k msgServer) AckTransferDappTx(goCtx context.Context, msg *types.MsgAckTransferDappTx) (*types.MsgAckTransferDappTxResponse, error) {

Example xamdata

[
  {              // REQUEST 1 EXAMPLE FORMAT
    {            // dictionary of denom indexes and amounts to transfer, for 0 value tx empty brackets {}
      "<uint64>": "<uint256>",                // fungible token syntax
      "<uint64>": "<uint256>,<uint256>,...",  // non-fungible token syntax (comma separated IDs)
      "<uint64>": "<uint256>-<uint256>",      // non-fungible token syntax (ranges), NFT id on the left <= NFT id on the right
      "<uint64>": "<uint256>-<uint256>,<uint256>,...",  // comma and range syntax can be combined together for NFT tokens
      ...        // NO other value-transfer formats are allowed
    },
    "<uint64>",    // source_dapp - Index of the source application where assets/data originate. Value 0 = deposit from outside ABR.
    "<uint64>",    // source_account - Index of the account address from which funds are being transferred.
    "<uint64>",    // dest_dapp - Index of the destination application receiving the transfer/data.
    "<uint64>",    // dest_beneficiary - Account ID of the destination beneficiary receiving the assets.
    "<string>"     // messages - Custom-formatted data to be included in the message for cross-application messaging. Can be empty.
  },
  { ... }, // REQUEST 2
  { ... }, // REQUEST 3
  {             // RESPONSE 1 EXAMPLE FORMAT
    "<uint64>",  // xid - MUST be different than 0
    "<uint64>",  // drc/src - a response code
    "<string>"   // drm/srm - a destination or source app response message (optional)
  },
  { ... }, // RESPONSE 2
  { ... }  // RESPONSE 3
]

• If dest_app == 0 and the messages (called xam in KIP) property of the xamdata is not null, the ABR should recognize that messages contains messages of type []sdk.Msg{} to be executed by SEKAI. If dest_app =/= 0, the XAM is simply registered, messages don't need to be processed by ABR since it is the responsibility of the destination app to monitor incoming XAMs and process custom instructions if any.

• All asset transfers are processed by ABR no matter the value of dest_app. Applications monitor the ABR for XAMs and respond during session submissions using xamdata (see above). ABR monitor incoming RESPONSE messages, process them and settle transfer according to following logic:

• Deposits need destination app confirmation within 2 blocks or twice the application's update_time_max whichever is bigger. If not confirmed, ABR doesn't settle and edit XAM with irc code 402.

• Withdrawals do not need confirmation they are automatically settled after the same set time with ABR returning irc code 200. Can be confirmed by the source app to speed processing up.

• If dest_app == 0, transactions destined for SEKAI are unsigned; if the Session submission (and by extension its xamdata) are accepted by Verifiers, they are signed by the application's public key.

• Transactions destined for SEKAI may or may not be valid, however if one transaction is invalid the Session containing the xamdata should fail and all assets transfer within the same xamdata should also fail even if Verifiers approved the Session submission. Conversely, if any asset transfer within the xamdata fails, the Session must fail as well. All or nothing.

• Use parameter of the transition-dapp CLI should be explicit about the necessity to provide xamdata