Skip to content
This repository has been archived by the owner on Jan 3, 2023. It is now read-only.

Eudico and Mir mempools pipeline #253

Merged
merged 10 commits into from
Sep 30, 2022
Merged

Eudico and Mir mempools pipeline #253

merged 10 commits into from
Sep 30, 2022

Conversation

dnkolegov
Copy link
Collaborator

This PR integrates Eudico and Mir mempools with each other.

@codecov-commenter
Copy link

codecov-commenter commented Sep 13, 2022

Codecov Report

Merging #253 (23ae70f) into eudico (856b61e) will decrease coverage by 0.02%.
The diff coverage is 98.70%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           eudico     #253      +/-   ##
==========================================
- Coverage   23.94%   23.92%   -0.03%     
==========================================
  Files         608      607       -1     
  Lines       65726    65701      -25     
==========================================
- Hits        15738    15718      -20     
+ Misses      47197    47195       -2     
+ Partials     2791     2788       -3     
Impacted Files Coverage Δ
chain/consensus/mir/pool/handlers/ids.go 100.00% <ø> (ø)
chain/consensus/mir/mine.go 68.04% <92.30%> (+1.73%) ⬆️
chain/consensus/mir/manager.go 72.93% <100.00%> (-1.98%) ⬇️
chain/consensus/mir/pool/fifo/fifo_pool.go 100.00% <100.00%> (ø)
chain/consensus/mir/pool/handlers/batches.go 100.00% <100.00%> (+6.89%) ⬆️
chain/consensus/mir/pool/pool.go 63.63% <100.00%> (-3.04%) ⬇️
chain/consensus/mir/state_manager.go 80.62% <100.00%> (ø)
chain/consensus/tspow/consensus.go 41.61% <0.00%> (-8.06%) ⬇️
chain/consensus/tspow/mine.go 58.46% <0.00%> (-4.62%) ⬇️
chain/messagepool/selection.go 47.69% <0.00%> (-4.43%) ⬇️
... and 12 more

@dnkolegov dnkolegov changed the title Draft: Eudico and Mir mempools pipeline Eudico and Mir mempools pipeline Sep 19, 2022
}

receivedRequests := <-submitChan
mpdsl.RequestTransactionIDs(m, mc.Self, receivedRequests, &requestTxIDsContext{receivedRequests})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I was probably wrong about only having to change this function. I didn't realize that the transaction IDs still must be computed. This implementation only gets the transactions from outside and has their IDs computed, but does not include them in the batch that is emitted as an event. In a strange way it probably works, just delayed, but this is not what I had in mind. What I meant is to directly emit a batch with the transactions received through the channel, without any buffering. For that, there needs to be more change to the module implementation.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me this is a feature.

I can delete calling of mpdsl.RequestTransactionIDs and implement hashing without sending an event but it will be also called later in batch reconstruction that is a not part of mempool.

Let's discuss in sync

tx := state.TxByID[txID]
for i := range txIDs {
tx := context.txs[i]
commonState.TxByID[txIDs[i]] = tx
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why we still save the transaction in the commonState buffer? It would be nice if this buffer didn't exist at all and the transactions were directly added in the new batch and immediately forgotten.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

tx := state.TxByID[txID]
for i := range txIDs {
tx := context.txs[i]
commonState.TxByID[txIDs[i]] = tx

// TODO: add other limitations (if any) here.
if txCount == params.MaxTransactionsInBatch {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check should probably not be enforced here any more. The handler should just take all transactions it receives and put them in a batch. The limit should be enforced when the transactions are fetched from the Eudico mempool.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Copy link
Contributor

@matejpavlovic matejpavlovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very good! I think we can merge this as the first round, and continue working on further improvements in a different PR.
Thanks!

@dnkolegov dnkolegov merged commit b43b652 into eudico Sep 30, 2022
@dnkolegov dnkolegov deleted the mirmempool1 branch September 30, 2022 07:54
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants