Query payment_queryInfo no longer works on Kusama

[Mama1emon]

Description

The request stopped working. All nodes return the same response. Example, https://kusama-rpc.polkadot.io/ We also checked on polkadot.js.

Request

{
   "method": "payment_queryInfo",
   "params": [
      "0x45028400B21FCF23C89DCFAE0FDEB3A5F5FBEF45514A5AE8AEE14F0A728D9A6C374499B200EB6CC55D16E5C1CE17BB1139DDC644DA3A4C8161F206D773169F64E4A05262A637A3F5FF7242A7849593C05169AE4F3A0CD44A411BD52C67FC31DC483AB8190BA60600000400003C7CF2BC7EC6CF2EFEB22193093D9F5F8999208C8ED8C9AF9F3EC940CC54E08E0B0040E59C3012"
   ],
   "jsonrpc": "2.0",
   "id": 4
}

Response

"message": "Unable to query dispatch info.",
       "data": "Execution failed: Execution aborted due to trap: wasm trap: wasm unreachable instruction exec
 uted\nWASM backtrace:\nerror while executing at wasm backtrace:\n    0: 0x6616 - <unknown>!rust_begin_unwind\n
     1: 0x312a - <unknown>!core::panicking::panic_fmt::hbb5a6b42001bdfec\n    2: 0x5cac63 - <unknown>!Transacti
 onPaymentApi_query_info"

[bee344]

Hi, just happened to see this, but we've had reports of similar errors and the cause is that since the last runtime upgrade a few days ago, the tx format on Kusama changed, with the addition of the SignedExtension CheckMetadataHash. I don't know how you are building the tx, but my guess is that you are using the old format and that's why the extrinsic is not being decoded correctly on pjs/apps either.

Edit: We as in the PJS team, not the SDK team.

Edit2: Also I think this query won't work with the new tx format, since it's already being deprecated. Refer here for an alternative.

[bkontur]

...the tx format on Kusama changed, with the addition of the SignedExtension CheckMetadataHash. I don't know how you are building the tx, but my guess is that you are using the old format and that's why the extrinsic is not being decoded correctly

yes, exactly, the same issue few days ago, check here: https://github.com/paritytech/polkadot-sdk/issues/4770

[Mama1emon]

Thanks, I finished working on the transaction assembly, and now payment_queryInfo returns a successful response. However, another issue has arisen. The author_submitExtrinsic request returns a new error when I send the transaction in the new format.

Request:

{
   "id": 0,
   "jsonrpc": "2.0",
   "method": "author_submitExtrinsic",
   "params": ["0x45028400b21fcf23c89dcfae0fdeb3a5f5fbef45514a5ae8aee14f0a728d9a6c374499b200c8201f25951ded4f5912c631d7442aa110e145bb2b272728a9b90853441cdc9fc6600e4249a042d1796a5588098f2a533c553be15da9a0715b8db9bf5a935f05860400000400004e6d5dcc916c3e66e26f720f3042e3b9f0aab417210077c005c05f56532494540bf663668c6230"]
}

Response:

{
   "jsonrpc": "2.0",
   "error": {
      "code": 1002,
      "message": "Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm tra
p: wasm `unreachable` instruction executed\nWASM backtrace:\nerror while executing at wasm backtrace:\n    0: 
0x6616 - <unknown>!rust_begin_unwind\n    1: 0x312a - <unknown>!core::panicking::panic_fmt::hbb5a6b42001bdfec\
n    2: 0x5ad90a - <unknown>!TaggedTransactionQueue_validate_transaction",
      "data": "RuntimeApi(\"Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` ins
truction executed\\nWASM backtrace:\\nerror while executing at wasm backtrace:\\n    0: 0x6616 - <unknown>!rus
t_begin_unwind\\n    1: 0x312a - <unknown>!core::panicking::panic_fmt::hbb5a6b42001bdfec\\n    2: 0x5ad90a - <
unknown>!TaggedTransactionQueue_validate_transaction\")"
   },
   "id": 0
}

[bee344]

Could you share the params used for the payload so we can recreate it? The tx you submitted is wrong, but it would be easier to see what's wrong if you tell us what you wanted to do in the first place

[Mama1emon]

I am trying to send Kusama from one address to another. This code works for Polkadot and Polkadot-like blockchains. But after the update, it stopped working for Kusama.

First, I create a transaction for signing – here. Then, I create a transaction using the already signed transaction to send with the author_submitExtrinsic method – here.

Edit: transaction's params

destinationAddress = EM9jxKiiB4vU1C66Wg7MzFxNXJmY4mPgpPVafK1Kjw8FHyj
amount = 53199820448758
era = 22
nonce = 0
tip = 0
mode (new param) = false
runtimeVersion = 1002005
txVersion = 26
genesis = [-80, -88, -44, -109, 40, 92, 45, -9, 50, -112, -33, -73, -26, 31, -121, 15, 23, -76, 24, 1, 25, 122, 20, -100, -87, 54, 84, 73, -98, -93, -38, -2]
eraBlockHash = [-27, -89, 52, 25, -125, 88, -119, -3, 125, -105, -115, -56, -97, -66, 40, 2, -30, 30, 77, 80, 111, -98, 49, -35, 54, 61, -117, -54, 46, 117, 124, 10]

[bee344]

For the unsigned tx, you need to set a value for mode. If you are not using CheckMetadataHash, set it to 0, which in the encoded unsigned would be 00 before the specVersion (runtimeVersion as you put it). But you also need to add the metadata for the CheckMetadataHash at the end of the payload, if mode == 0 then the metadata is just an empty byte 00, otherwise is the value of the encoded merkleized metadata. In the signedTx, the mode remains placed before the callIndex, but the metadata is no longer present.

You can check this example for a payload 0xa40403008eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a480700e40b54023502000000154a0f001a000000b0a8d493285c2df73290dfb7e61f870f17b41801197a149ca93654499ea3dafeb7d7e4a0779f43d14842b9ce7ad326c933dceb6a75005224467e7ca28d44daff00 and this one for the signedTx 0x45028400d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d01f84e86e933c05203393a56522869e1f48fac0525ad432ccb0e7321ace8ef302e73093369dcfa990491eb343371b7baa6c647a64e783fc2bf22c91202e0478886d5030000000403008eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a480700e40b5402. You can decode those here.

Edit: clarified metadata append

[Mama1emon]

Thank you for the detailed and prompt response. Now it's clear how this should work.

Can you tell me if similar changes are planned for Polkadot or other blockchains?

[bee344]

For Polkadot this same change is set to take effect on block 21,455,000, which is about July 1st. For the parachains, no clue

[bkchr]

@Mama1emon yes, all the system parachains are also moved to this signed extension. So, after 1 July, Polkadot, Kusama and all their system chains should be migrated.

@Mama1emon can you tell me what you are working on? We have done quite a lot of communication before to inform people about this breaking change, but apparently we didn't reached you. If you tell me what you are working on, I can ensure that next time you will be informed as well.

[Mama1emon]

@bkchr, I apologize for the delayed response.

I am working on the Tangem project. Tangem Wallet - is a cold crypto wallet. We have the support of Polkadot, Kusama, and some parachains. There are a lot of clients who use these chains, so we need to have an update from your side for sure. We would be very grateful if we could receive notifications about upcoming updates at this address: development@tangem.com.

Could you please clarify regarding the current update: 1) Does it have a specific specVersion? 2) For the AlephZero, Joystream, and Bittensor blockchains, at which block or specVersion will the update take effect?

[bkchr]

I am working on the Tangem project. Tangem Wallet - is a cold crypto wallet. We have the support of Polkadot, Kusama, and some parachains. There are a lot of clients who use these chains, so we need to have an update from your side for sure. We would be very grateful if we could receive notifications about upcoming updates at this address: development@tangem.com.

CC @SBalaguer @anaelleltd

Could you please clarify regarding the current update:

1. Does it have a specific specVersion?

2. For the AlephZero, Joystream, and Bittensor blockchains, at which block or specVersion will the update take effect?

For Polkadot/Kusama it will be 1002005 as seen here: https://github.com/polkadot-fellows/runtimes/releases/tag/v1.2.5

BTW, it would be better if you use the metadata to detect the signed extensions used by a runtime. This way you can detect this without relying on spec versions.

[SBalaguer]

@Mama1emon just to add to the conversation before, I believe you can track Bittensor's development for this feature here: https://github.com/opentensor/subtensor/issues/428