Add edge dependency type for tracking transaction data dependencies

[ryle-goehausen]

Need an edge type encapsulating dependencies between src / dst addresses reflecting the last hash which updated that address. This is to allow data locality performance optimizations for storing sub-partitions of the graph. Structure should link (in order) the most recent state transition associated with each address, and should encapsulate the TX edge hash as a data object on the edge. Need to talk with DAG / chain state DAO in order to accomplish and create verification service during edge construction to verify state accuracy.

[Nikolaj-K]

This weekend I'm going to try and understand the cell/edge setup more.

• Here, if you speak of src / dst, is that asset transactions source and dst? If so, does this at all relate to docking of dApps to the network? Or is it a communication channel (maybe during consensus), and if so, in what context?
• The sentence ends in "that address", but what is the "that" here? If you speak of state transition, is that the change of a nodes view? If so, is each such state transition actually somehow captured/remembered in the form of some hash or data here?
• What is "object on the edge". Is data on the edge something that can be modified after the edge has been instantiated?

Sorry for the possibly silly questions.

[ryle-goehausen]

@Nikolaj-K sorry for delay in answering,

Yes, in the initial examples src / dst reflect transaction addresses. WRT to dApp support we haven't finalized the JSON schema for validation, but it will be functionally similar to https://developer.holochain.org/Validation_Functions -- dApps need hashes that they're tracking for consensus to follow dependency rules in order for performance and prevention of network pollution.

Re: Transaction dependencies, these are an initial obvious demonstration of benefits of dependency information. We need an edge type that does ordering per address which can then be captured in a checkpoint. It should be very similar to the 'Transaction Block' proposed by CHECO / the Nano data structure.

'That address' refers to both source and destination, i.e. the dependencies for verifying only really require the source address for the balance check, but as long as we're capturing state information adding the last update to the destination helps with security as well.

The state transitions are based on the initial nodes view, but we don't want redundancy of different views. Should there be a conflict in the ordering there'll be a deterministic function to select the higher reputation view as long as there's no state conflict. State conflicts will eventually require more complex logic to resolve including votes.

Re: 'Object on the edge' -- this just means the edge should be between SRC / DST address and contain references to the last hashes associated with those addresses as the data. Similar to how we represent a CB as an edge between 2 tips with an associated piece of data (representing a collection of hashes,) we also need an edge between SRC / DST with dependency data attached on it.

We've had more discussion on the nomenclature here and it's perhaps a bit confusing of our use of the word edge, we may change some of the terminology. The final 'visualized form' of the data is where every checkpoint is a vertex, and 'edges' are just representative of hash linkages referenced in their data, but that is different from what we're using edge to represent at a data level (due to signing requirements.)

No silly questions, thanks for asking!

[ryle-goehausen]

Temporarily -- we're going to track dependencies per-account for light node validating a subset of the ancestry off-chain -- the full implementation of this ticket will have to wait.