Bugfix/added gasLimit check when creating cross shard miniBlocks #350
Conversation
…ner this way, and the logic as well.
…t-calls-in-the-same-miniblock
integrationTests/testInitializer.go
Outdated
| round = IncrementAndPrintRound(round) | ||
|
|
||
| for _, idProposer := range idxProposers { | ||
| proposedNode := nodes[idProposer] |
There was a problem hiding this comment.
proposerNode?
as no one is proposing a node for anything.
integrationTests/testInitializer.go
Outdated
| startTime := time.Now() | ||
| ProposeBlock(nodes, idxProposers, round) | ||
| elapsedTime := time.Since(startTime) | ||
| fmt.Printf("Block Created in %s\n", elapsedTime) |
There was a problem hiding this comment.
I see this block propose & sync is repeated below as well, can we extract this in a function?
Also why is this done in a loop here and also in another loop below?
It is not clear why this is required.
There was a problem hiding this comment.
the loop below is needed, to propagate all the modifications through all the shards. After the last transactions were proposed, it needs 5 rounds to reach the destination shard, because of finality and asynchronous processing through metachain.
There was a problem hiding this comment.
then add a comment for the second loop why it is needed
integrationTests/testInitializer.go
Outdated
| ) uint64 { | ||
|
|
||
| // propose until pool is cleared | ||
| for i := numInTxs; i != 0; { |
There was a problem hiding this comment.
these for loops are confusing
There was a problem hiding this comment.
There is not repeat until, or do while. So the propose is needed to be done at least once. Than to continue proposing until the pools are empty.
| SyncBlock(t, nodes, idxProposers, round) | ||
| round = IncrementAndPrintRound(round) | ||
|
|
||
| for _, idProposer := range idxProposers { |
There was a problem hiding this comment.
What is this trying to do?
From what I see you are selecting the first node with no transaction with its shard as destination(or a nil tx pool), from a consecutive list of proposing nodes.
You are also modifying the i here which is used in the above for loop, so you are exiting both for loops when you have found one proposing node with no transactions. Is this a waiting loop until one proposer is found that has no remaining txs for his shard in pool? can you extract in a function and make it clearer?
There was a problem hiding this comment.
This is a function to continue proposing blocks until there are no more transactions in the pool.
…ntract-calls-in-the-same-miniblock' into bugfix/en-3496-too-many-smart-contract-calls-in-the-same-miniblock
…t-calls-in-the-same-miniblock
…t-calls-in-the-same-miniblock
…t-calls-in-the-same-miniblock
…t-calls-in-the-same-miniblock
…ce in its account
…t-calls-in-the-same-miniblock
…t-calls-in-the-same-miniblock
sasurobert
deleted the
bugfix/en-3496-too-many-smart-contract-calls-in-the-same-miniblock
branch
Added gasLimit check when creating a cross shard miniblock. Example of the problem: shard 0 creates a miniblock with 1000 smart contract calls, all the calls are for a SC in shard 1. shard 1 when reading the from metachain the needed miniblocks to process, tries to do it, but fails as he has no time to process all those transactions.