search

ledgerloops / strategy-pit

Testing ground for LedgerLoop strategies
Apache License 2.0
0 stars 0 forks source link

Designing nack messages #39

Open michielbdejong opened 1 month ago

michielbdejong commented 1 month ago

In the light of #37 I'm thinking of nack messages that indicate that a node knows it has no further loops. This can be because it is a leaf, or because all its other neighbours have sent a nack message. So I'm going to track nack messages in the FriendsEngine. As an extra step in the meet process, a meet will either be followed by a nack, or be replied to with an ack or a nack, and the flood probe for the newly created link will only be sent if no nack was sent and an ack was received.

I'm also considering ack in response to probe but I think that will be too expensive.

michielbdejong commented 1 month ago

Thanks to ack/nack on meet, the DISBURSEMENT transactions have become orders of magnitude faster. Can now run up to line 7950 (27 STANDARD and 7922 DISBURSEMENT transactions) in 29 seconds.

michielbdejong commented 1 month ago

I'm feeling like I want to rewrite a node implementation from scratch. The separation between FriendsEngine and ProbesEngine (which itself keeps track of friends), all wired through the main Badger class with events, is annoying.

Are events (reacting to incoming messages) even the right approach? Or should the design be more state-driven (incoming messages update the state, and at any point the node can decide to look at its state and trigger some action)? The latter feels like it may become cleaner, so the node has a better model of its environment and doesn't depend on replies from other nodes to continue what it was doing.

michielbdejong commented 1 month ago

In any case, the Sarafu data set has 1,000,000 transactions of which 422,721 are standard, across 55,000 nodes, so we'll have to do a about 4 orders of magnitude more than what the simulation is handling right now.

michielbdejong commented 1 month ago

In any case, we don't want to trigger a flood probe from every meet event, and we want to build in queuing and filtering, and in general be much more deliberate about when a probe is forwarded.

Maybe nacks coming back from probes can be very useful to identify dead-end branches. Each node should keep state of that. When two nodes meet, if previously both of them were on acyclic trees, they don't know if they're on the same acyclic tree or on a different one. That's what the probe checks. Does it need to bounce back from all leaves to prove that?

Leaf nodes never have to participate in any probes Line nodes can just pass them on transparently, unless maybe a special line probe to detect perfect circles. Fork nodes play a role though, and should try to find one loop per trade pair.