Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consensus optimization during transaction request #1077

Closed
shargon opened this issue Aug 29, 2019 · 4 comments
Closed

Consensus optimization during transaction request #1077

shargon opened this issue Aug 29, 2019 · 4 comments
Assignees
Labels
consensus Module - Changes that affect the consensus protocol or internal verification logic enhancement Type - Changes that may affect performance, usability or add new features to existing modules. ready-to-implement Issue state: Ready to be implemented or implementation in progress

Comments

@shargon
Copy link
Member

shargon commented Aug 29, 2019

When reviewing #1040 an issue was discovered and a possible optimization.

The first thing we can see is in the following lines

taskManager.Tell(new TaskManager.RestartTasks
{
Payload = InvPayload.Create(InventoryType.TX, hashes)
});

We are creating an inventory of the pending transaction hashes, but calling the wrong method, we should call

public static IEnumerable<InvPayload> CreateGroup(InventoryType type, UInt256[] hashes)
{
for (int i = 0; i < hashes.Length; i += MaxHashesCount)
yield return new InvPayload
{
Type = type,
Hashes = hashes.Skip(i).Take(MaxHashesCount).ToArray()
};
}

Because it control the limits by MaxHashesCount and the other doesn't.

This is the first issue, the next one is an improve.

As you know, in P2P was added a compression mechanism (#710), compression is ver useful for improve the TPS, but is better on bigger messages than smaller. So if a node is asking about 500 TX, why we should send it one by one? We should pack all of this tx, and send in a bulk message. Is more optimal and can save resources.

UInt256[] hashes = payload.Hashes.Where(p => sentHashes.Add(p)).ToArray();
foreach (UInt256 hash in hashes)
{
switch (payload.Type)
{
case InventoryType.TX:
Transaction tx = Blockchain.Singleton.GetTransaction(hash);
if (tx != null)
Context.Parent.Tell(Message.Create(MessageCommand.Transaction, tx));
break;
case InventoryType.Block:
Block block = Blockchain.Singleton.GetBlock(hash);
if (block != null)
{
if (bloom_filter == null)
{
Context.Parent.Tell(Message.Create(MessageCommand.Block, block));
}
else
{
BitArray flags = new BitArray(block.Transactions.Select(p => bloom_filter.Test(p)).ToArray());
Context.Parent.Tell(Message.Create(MessageCommand.MerkleBlock, MerkleBlockPayload.Create(block, flags)));
}
}
break;
case InventoryType.Consensus:
if (Blockchain.Singleton.ConsensusRelayCache.TryGet(hash, out IInventory inventoryConsensus))
Context.Parent.Tell(Message.Create(MessageCommand.Consensus, inventoryConsensus));
break;
}
}
}

@shargon shargon added the consensus Module - Changes that affect the consensus protocol or internal verification logic label Aug 29, 2019
@shargon
Copy link
Member Author

shargon commented Sep 2, 2019

Please take a look @eryeer and @Tommo-L

@Tommo-L
Copy link
Contributor

Tommo-L commented Sep 3, 2019

Good idea, we have seen

@eryeer
Copy link
Contributor

eryeer commented Sep 4, 2019

When reviewing #1040 an issue was discovered and a possible optimization.

The first thing we can see is in the following lines

taskManager.Tell(new TaskManager.RestartTasks
{
Payload = InvPayload.Create(InventoryType.TX, hashes)
});

Thanks for your great idea, but I found the function OnRestartTasks in TaskManager recreate the payload into group, and then broadcast the payload.

foreach (InvPayload group in InvPayload.CreateGroup(payload.Type, payload.Hashes))
system.LocalNode.Tell(Message.Create(MessageCommand.GetData, group));

Do we need to create payload into group twice? @shargon

@shargon shargon added design Issue state - Feature accepted but the solution requires a design before being implemented enhancement Type - Changes that may affect performance, usability or add new features to existing modules. labels Sep 5, 2019
@shargon
Copy link
Member Author

shargon commented Sep 7, 2019

Thanks @eryeer I will focus on the second part then, because as you said, the first one is already good.

@shargon shargon added the ready-to-implement Issue state: Ready to be implemented or implementation in progress label Sep 7, 2019
@shargon shargon self-assigned this Sep 9, 2019
@lock9 lock9 removed the design Issue state - Feature accepted but the solution requires a design before being implemented label Sep 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consensus Module - Changes that affect the consensus protocol or internal verification logic enhancement Type - Changes that may affect performance, usability or add new features to existing modules. ready-to-implement Issue state: Ready to be implemented or implementation in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants