BCS TransactionKind for sui_devInspectTransaction -> PaySui

@amnn

As I am writing in Python, and have access to BCS serialize/deserialize I have some questions on how to represent PaySui values. Here is a json equivalent of what I have:

{
  "Single": {
  "PaySui": {
    "amounts": [
      1000000
    ],
    "coins": [
      {
        "digest": "m+//CANeho7XQRZIjKgt7xZQumg/CEayvmGfZHStKTQ=",
        "object_id": "0x09cf4a451a5bc23d7f2130cf2897aa41212874bc",
        "version": 688
      }
    ],
    "recipients": [
        "cc9e52e70a2233fe80fea5458a24b94272a1b0e9"
    ]
  }
 }
}

“Single” and “PaySui” translates to invariants 0, 5 respectively
Here is the list of bytes prior to base64 encoding:
[0, 5, 1, 20, 87, 32, 11, 222, 234, 36, 110, 94, 59, 37, 198, 115, 35, 47, 235, 70, 8, 226, 156, 93, 176, 2, 0, 0, 0, 0, 0, 0, 32, 155, 239, 255, 8, 3, 94, 134, 142, 215, 65, 22, 72, 140, 168, 45, 239, 22, 80, 186, 104, 63, 8, 70, 178, 190, 97, 159, 100, 116, 173, 41, 52, 1, 20, 212, 120, 254, 173, 89, 93, 24, 147, 228, 177, 174, 173, 38, 105, 189, 176, 159, 224, 227, 15, 1, 64, 66, 15, 0, 0, 0, 0, 0]

And the base64 of that:
AAUBFFcgC97qJG5eOyXGcyMv60YI4pxdsAIAAAAAAAAgm+//CANeho7XQRZIjKgt7xZQumg/CEayvmGfZHStKTQBFNR4/q1ZXRiT5LGurSZpvbCf4OMPAUBCDwAAAAAA

And here is the result I get from calling Sui:
Inspect failure -> {'code': -32000, 'message': 'invalid length 0, expected an byte array of size 32'}

Question #1: Are digest,obect_id in coins and recipients in PaySui serialized as strings or array of bytes (i.e. decoded base64 bytes)? If as bytes, is the vector length encoded?

Or if someone can give me the correct list of bytes (pre-base64 encoded) I can probably back my way into it.

Also, in Rust (messages.rs) PaySui shows:

pub struct PaySui {
    /// The coins to be used for payment.
    pub coins: Vec<ObjectRef>,
    /// The addresses that will receive payment
    pub recipients: Vec<SuiAddress>,
    /// The amounts each recipient will receive.
    /// Must be the same length as recipients
    pub amounts: Vec<u64>,
}

Whereas in 0.24.0 rpc.discover schema for PaySui the order is different:

        "PaySui": {
          "description": "",
          "type": "object",
          "required": [
            "amounts",
            "coins",
            "recipients"
          ],
          "properties": {
            "amounts": {
              "description": "The amounts each recipient will receive. Must be the same length as amounts",
            },
            "coins": {
              "description": "The coins to be used for payment",
            },
            "recipients": {
              "description": "The addresses that will receive payment",
            }
          }
        },

There is also a difference between ObjectRef (Rust vs. schema)

5 Likes

cc @tnowacki, I believe PaySui and PayAllSui are currently not supported in devInspectTransaction, because they treat the gas object specially and so do not play nice with the loosened restrictions that devInspectTransaction has around gas.

For now, I would recommend use dryRunTransaction for these transaction kinds. In the meanwhile, we are working on combining these two APIs into one, which will support everything.

3 Likes

Ahhh, ok… I will use Transfer to ensure I have the BCS right (again, working in Python) and I’ll watch for the Pay* support at a later drop

4 Likes

cc: @tnowacki
I don’t know if any are working. I’ve just tried TransferObject and pretty much get the same results. If I structure it as in crate messages.rs (note that in schema the fields are reversed)

pub struct TransferObject {
    pub recipient: SuiAddress,
    pub object_ref: ObjectRef,
}

I get this array: [0, 0, 20, 212, 120, 254, 173, 89, 93, 24, 147, 228, 177, 174, 173, 38, 105, 189, 176, 159, 224, 227, 15, 20, 87, 32, 11, 222, 234, 36, 110, 94, 59, 37, 198, 115, 35, 47, 235, 70, 8, 226, 156, 93, 176, 2, 0, 0, 0, 0, 0, 0, 32, 155, 239, 255, 8, 3, 94, 134, 142, 215, 65, 22, 72, 140, 168, 45, 239, 22, 80, 186, 104, 63, 8, 70, 178, 190, 97, 159, 100, 116, 173, 41, 52]

base64 encoded: AAAU1Hj+rVldGJPksa6tJmm9sJ/g4w8UVyAL3uokbl47JcZzIy/rRgjinF2wAgAAAAAAACCb7/8IA16GjtdBFkiMqC3vFlC6aD8IRrK+YZ9kdK0pNA==

And this error: Inspect failure -> {'code': -32000, 'message': 'invalid length 0, expected an byte array of size 32'}

If I change the field order as in schema:
I get this array: [0, 0, 20, 87, 32, 11, 222, 234, 36, 110, 94, 59, 37, 198, 115, 35, 47, 235, 70, 8, 226, 156, 93, 176, 2, 0, 0, 0, 0, 0, 0, 32, 155, 239, 255, 8, 3, 94, 134, 142, 215, 65, 22, 72, 140, 168, 45, 239, 22, 80, 186, 104, 63, 8, 70, 178, 190, 97, 159, 100, 116, 173, 41, 52, 20, 212, 120, 254, 173, 89, 93, 24, 147, 228, 177, 174, 173, 38, 105, 189, 176, 159, 224, 227, 15]

base64 encoded: AAAUVyAL3uokbl47JcZzIy/rRgjinF2wAgAAAAAAACCb7/8IA16GjtdBFkiMqC3vFlC6aD8IRrK+YZ9kdK0pNBTUeP6tWV0Yk+Sxrq0mab2wn+DjDw==

This error:Inspect failure -> {'code': -32000, 'message': 'unexpected end of input'}

3 Likes