Tweak propagation of individual transactions in network

[NikVolf]

No description provided.

[bkchr]

As already said in Riot, I'm against this solution. Why not create a proper implementation directly?

[NikVolf]

As already said in Riot, I'm against this solution. Why not create a proper implementation directly?

Why do we need to complicate protocol if this will be enough?

It is used in Ethereum and other networks successfully

[NikVolf]

Also, this is complementary

If we choose to complicate protocol, we still want to flood to sqrt(count) peers immediately to reduce latency

And announce new transactions hashes to everyone.

Like in this proposal:
ethereum/EIPs#2465

[bkchr]

To cater for degenerate topologies, transactions cannot be broadcast logarithmically, rather they need to be transferred linearly to all peers. With N peers, each node will transfer the same transaction N times (counting both directions), whereas 1 would be enough in a perfect world. This is a significant waste.

It says that they don't use logarithmically propagation for transactions.

[NikVolf]

It says that they don't use logarithmically propagation for transactions.

They do with referenced eip (it's already live)

But yeah, probably this alone is not enough due to topology issues, I'll add announce/retrival here as well

[tomusdrw]

It looks reasonable although I would say that the timer-based propagation should go to sqrt { min: 5 (or even 10) } and the single-transaction should be broadcast to everyone.

Also I think it would be good to implement pool reconciliation protocol at some point soon :)

[NikVolf]

@tomusdrw we already have timer-based propagation for every peer on timer (once in 3s)

also see paritytech/polkadot-sdk#553

[tomusdrw]

@tomusdrw we already have timer-based propagation for every peer on timer (once in 3s)

That's why I said I think it should be the other way around. The timer-based propagation (propagate_transactions/0) should be sqrt while newly imported transactions (propagate_transaction/1) can be sent to everyone (since the packets are small) - we might introduce some batching though.

[NikVolf]

@tomusdrw we already have timer-based propagation for every peer on timer (once in 3s)

That's why I said I think it should be the other way around. The timer-based propagation (propagate_transactions/0) should be sqrt while newly imported transactions can be sent to everyone (since the packets are small) - we might introduce some batching though.

ah, right

@tomaka just mentioned that in new (current) protocol messages are batched automatically, so if you dispatch several messages for particular peer, they'll go batched on wire

[NikVolf]

The timer-based propagation

@tomusdrw I think with paritytech/polkadot-sdk#553 resolved we can just drop timer-based propagation

[grbIzl]

@arkpar was saying, that we have to include peers with authority role into the set for propagation anyway

[gnunicorn]

closing because of inactivity.