Technical ideas required/very-nice-to-have for SabVM

[IaroslavMazur]

Here is a list of ideas (in no particular order) which I've thought of while brainstorming how SabVM would function/could be made to function more efficiently:

• For each node/address, the static balance would have to be accompanied by the date at which the balance has last been calculated, so that the next time it needs to be re-calculated, that date could be used as a starting point (i.e. starting from that point, see how much the incoming Streams have streamed in - and how much the outgoing Streams have streamed out);

• To parse the Stream network/sub-graph in a more efficient way (with the smallest-possible no. of nodes being re-evaluated multiple times), we could keep track - in an independent, protocol-level collection - of the up-to-date state of all of the "source" nodes/Senders (that only have outgoing edges/Streams) - and to start each rebalancing from this subset of nodes;

• To simplify the rebalancing for a node, it'd be very handy to have access to an up-to-date collection containing all of the Streams incoming for the node (where it is the Recipient). Implementing this would mean either

  • having an actual collection attached to every node (and maintained up-to-date at every Stream creation/deletion) - or
  • making the Stream relation/Directed Edge bidirectional.

@razgraf, @PaulRBerg

[PaulRBerg]

Good points all throughout. Have you already seen my preliminary work (PoC) in V3 Core?

the static balance would have to be accompanied by the date at which the balance has last been calculated,

This is how I designed it in V3 Core.

of the up-to-date state of all of the "source" nodes/Senders (that only have outgoing edges/Streams)

Again, how it's designed in V3 Core. But there's a difficulty here:

it'd be very handy to have access to an up-to-date collection containing all of the Streams incoming for the node

This is fundamentally an issue about data structures in Rust, and I don't see how we can be of help with this without concrete references to external libraries like Petgraph.

making the Stream relation/Directed Edge bidirectional.

Since edges are normally streams, I recommend against introducing bidirectionality just for some non-essential data structuring purpose. If we do this, we would ascribe another meaning to edges, and we don't want that.

[IaroslavMazur]

I don't understand the value of starting a discussion about this without making specific, concrete references to graph libraries (you haven't made such references in the OP).

The OP is a high-level set of ideas/suggestions, not a specification for their implementation. The "concrete" graph libraries to be used could/should be decided after the suggestions are deemed worth implementing.

---

I think this is a question about external libraries

Hm... Not really.

You said that you "recommend against introducing bidirectionality just for some non-essential data structuring purpose", and I tried to explain why the example above (the Dynamic -> Static balance transition) wouldn't be just "some non-essential data structuring purpose" - and that it can't really be addressed efficiently, w/o having bi-directional graph edges.

[PaulRBerg]

The OP is a high-level set of ideas/suggestions

Yes, and I have criticized one of the ideas as being not useful/ relevant, implicitly suggesting that it should be removed or crossed-out.

that it can't really be addressed efficiently, w/o having bi-directional graph edges

My point: this is an abstraction. It's something that external graph libraries do. We don't need to ponder these issues ourselves unless we are confronted with a particular problem situation in the SabVM code base.

Premature optimization is the root of all evil.

[PaulRBerg]

Additional thoughts on this - @IaroslavMazur, I apologize for my two previous replies. They were unnecessarily abrasive.

You simply suggested implementing a reverse mapping of incoming streams - I can agree that that is helpful. Luckily, it turns out that we get this feature 'for free' if we use the Petgraph library.

[IaroslavMazur]

Alright, then 🤝

Given that we agree about the general utiity of the suggestions from the OP 9no matter whether we implement them directly/ourselves - or "inherit" from some other library we'll import in our code), it seems that there's nothing more to discuss in this thread.

If/when @razgraf agrees, as well, I'll close this discussion.

[razgraf]

LGTM 👏