Substrate: two transactions do not fit in one block

Created on 15 Jan 2020  路  9Comments  路  Source: paritytech/substrate

We started our own network from node-template without any changes in the code. Repository commit c6fc2e6. json-file was changed and attached below:
bn1spec_bal_raw.txt
At the moment the network can be seen at https://telemetry.polkadot.io/#list/cw_test
When we try to send two transaction simiusly they are not included in the same block, but are added one at a time to each sequential block. We tried to send our transactions from different computers, from different accounts and to different accounts, but still, transactions are included in a different blocks.
We tried it for a quite few times and right now it looks like that only one transaction can be included in the block.
screens:
photo_2020-01-15_05-43-08
photo_2020-01-15_05-43-02
photo_2020-01-15_05-43-05

Z0-unconfirmed

Most helpful comment

@alex-cloudwalk thanks for the logs, unfortunately due to a mistake on my side the logs do not contain a full info that would be needed, could you please re run with:
-ltxpool=trace,sc_basic_authority=trace?
The pool accepts both transactions and they are present in the pool at the same time, so I suspect it's most likely a block weight limit issues as @kianenigma mentioned. The logs would confirm our suspicions.

All 9 comments

Could you run the validator node with -lbasic_authorship=trace,txpool=trace and post the logs here?

  • what are the transactions exactly?
  • Have you changed MaximumBlockWeight and MaximumBlockLen? Increase them (to maybe the max_value even) and if it is solved it means the weight is preventing it. Though the logs from the pool validation should also tell us what is happening.
  1. Transactions are simple transfers from one account to another account, nothing special.
  2. We didn't touch those values, they must be default. But correct me if I'm wrong please, to change MaximumBlockWeight and MaximumBlockLen we should modify it from Rust code?

Yup from the rust code in the runtime top file /runtime/src/lib.rs

We again sent transactions today with logs turned on. Both transactions were sent on block 204330, one went to block 204331, the second went to 204332.
Logs from the Alice node: https://gist.github.com/alex-cloudwalk/7f77b330f4de8d208972d12be8211957
Logs from the Bob node: https://gist.github.com/alex-cloudwalk/780f051d1534b9708b7026ad2bc2b74e

@alex-cloudwalk thanks for the logs, unfortunately due to a mistake on my side the logs do not contain a full info that would be needed, could you please re run with:
-ltxpool=trace,sc_basic_authority=trace?
The pool accepts both transactions and they are present in the pool at the same time, so I suspect it's most likely a block weight limit issues as @kianenigma mentioned. The logs would confirm our suspicions.

@tomusdrw thanks for the quick response. Here are the logs with -ltxpool=trace,sc_basic_authority=trace:
Logs from the Alice node: https://gist.github.com/alex-cloudwalk/52107daae6335f740a4f3be266003a28
Logs from the Bob node: https://gist.github.com/alex-cloudwalk/928bc42e3f4f3c934d3943e67aecd37d

Take a look at this line: https://gist.github.com/alex-cloudwalk/928bc42e3f4f3c934d3943e67aecd37d#file-log__bob_validator_029_034-txt-L26
the block is full already, so it's definitely a weight issue as @kianenigma mentioned.

thanks for your help, @tomusdrw and @kianenigma

Was this page helpful?
0 / 5 - 0 ratings