Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Dandelion++ Thoughts on Timers/Scheduling #2880
@lehnberg's recent work on documenting our Dandelion++ impl #2723 got me thinking about some ways we could potentially simplify the timers and scheduling inherent in the "Dandelion Monitor" in Grin/MW and potentially make it more Grin-native.
Currently we kick off a background thread for the Dandelion Monitor. This runs every
We conveniently have block times of approx
We can simply trigger a single run of the "Dandelion Monitor" via the adapter for every
We get randomization for free because it is now based on which stem relay sees the latest block first (and is not dependent on when they see the tx itself).
I suspect (but this needs to be considered more) that this may actually improve the anonymity properties of Dandelion++. It removes any node specific timing information. All nodes are effectively running on the same coarse timer, based on blocks being approx 60s apart. We also get a decent amount of randomization due to the variation in block times.
This may also actually make Dandelion easier to reason about. There are a lot of moving parts and a large chunk of "black-box" behavior in term of timing around aggregation etc. If this was all based on underlying block times there would be fewer overlapping timers (and associated edge-cases) involved.
This has not been fully thought through but wanted to put some initial thoughts down and maybe get some feedback on this.
Glad the writing triggered this thinking! Initially, I like it as well.
This would also mean that the timestamp granularity becomes ~1 min, correct? Does that become a problem?
So if I understand correctly,
Indeed. Does it become predictable though? Once a new block is propagated, does it becomes fair to expect that most connected nodes in the network will fire the monitor within a certain interval?
Would it make sense for nodes to locally "blind" their actions with delays? (I.e. fire once a new block is propagated and after a random delay of
Moving to basing the timer on block intervals, how would transactions not already included in blocks be handled (somewhat echoing @lehnberg's first question)?
Otherwise, first impressions are there are some good improvements there. Will do more (re)reading on Dandelion++, and review the current code for some deeper feedback. Thanks for putting down your ideas!
It's potentially more restrictive but I'm not sure its a problem. The current
Yes. This is simply a callback/hook in our code that fires every time our local node sees a new block.
I think we lose a lot of the simplicity here if we then re-introduce a timer/delay.
The "stem phase" is distinct from the regular tx broadcast/propagation phase.
These proposed changes would only affect the
Edit: for example - it doesn't really matter how quickly you get a tx propagated and into the txpool of every node if miners only select txs once per block period.
Yeah, I think you might be right. What we're talking about here is firing a node's
I'm trying to think of what the implications would be if (A) this interval was very short (i.e. all nodes firing
As per the original D++ PR:
If (A), it would mean that fluffing would occur almost all at once across the network. If (B), it would be more sporadically. What impact would this have? Is it likely for there ever to be collisions, where multiple nodes fluff the same tx (aggregated with others or not) in the same block interval? Are there any other problems this could lead to?
I believe the proposed approach is favourable from the point of the fail safe mechanism (embargo timer), i.e. keeping track of a transaction and making sure it gets broadcasted in case a malicious node censors it. In the paper, timers are kept by each of the nodes, and padded with some randomness (to avoid the timer that fires first always to be that of the originating node). With the proposed approach, the node that first realizes that a transaction is missing is the node that fires
And depending on whether it's (A) or (B) above, other nodes would discover the same thing either fairly all at once, or in a staggered fashion. But I suppose only the few nodes on the network that acted as stem nodes will know that the transaction in question has been censored. So it would be important for this information to reach them and that they can act on this.
What happens when a node realises the embargo timer has expired? Does it fluff only that transaction or does it aggregate and fluff all the transactions it's got in its pool? The quote above suggests the latter. Similarly to what I was asking above, what would happen if there are multiple different versions of a transaction being fluffed on the network from different nodes at once?