RFC: Deprecate the slot-timestamp assumptions. Replace with edge-based derivation.

[Ben-PH]

Preamble

At the moment we have a tight-coupling assumption between a slot and the timestamp it occupies:

// the timestamp at which a particular period starts:
period_timestamp = genesis_timestamp + slot.period * period_interval;

// the interval between each slot within a period: The whole period is equally spread across the massa-networks threads.
let per_slot_interval = period_interval / thread_count;

// a given slots timestamp
let timestamp = period_timestamp + slot.thread * per_slot_interval

// with period interval of 16000ms and 32 slots, assuming the genesis timestamp is in milliseconds (period, thread_number):
assert_eq!(Slot(5, 4), genesis_timestamp + 80_000 + 2_000)

I propose that time be tracked through time-deltas that exist in edges. A blocks concept of where it is in the DAG is carried over to its when, with its DAG edges now having time-deltas as weights

/// a point in time where a block is expected
pub struct Block {
    // ...
    parent_blocks: Vec<Block>,
}
impl Block {
    pub fn get_time_stamp(&self, graph: &MassaGraph) -> Option<MassaTime> {
        graph.genesis_timestamp() + self.get_time_delta(graph)?
    }
    /// Recursively walks the masa-networks DAG to a "genesis-period", accumulating
    /// time-deltas along the way
    pub fn get_time_delta(&self, graph: &MassaGraph) -> Option<MassaTime> {

        // For this e.g., any parent will do, but...
        let Some(parent) = self.parent_blocks.get(0) else {
            // ...if it has no parents. let's just assume that it's at the start of this network in this e.g.
            return graph.delta_of_first_block_in_thread(self);
        };

        // Find the delta between said blocks
        let delta = graph.get_time_delta(self, parent)?;

        // Recurse to the the selected parent, accumulating the delta
        delta + parent.get_time_delta(graph)?
    }

This is a naive example implementation, but with some clever thinking, I see no reason why time complexity should be amortized to a single-pass O(n).

How this changes the notion of what's in the network:

• The slot no longer has the responsibility of time-keeping
• A block doesn't change its responsibilities: It's a node in a graph.
• An edge between blocks now has a "weight" in the form of a time-delta. In the example above, it would be handled by the MassaGraph

Goal if this idea:

• Time is now completely owned by the Network itself, as opposed to each individual slot.
• "When is this block", or "which block is closest to a given timestamp" is now coupled to the networks understanding of time, as opposed to a fixed iteration within the network.

[damip]

Thanks for this feedback. What you are describing is essentially using the Block Height for time relations instead of having predefined absolute timeslots. This is what is used in Tezos for example. Naturally, it is also an option that we explored (look at this old version of the paper: https://arxiv.org/pdf/1803.09029v2.pdf => no slots ! ).

We ended up switching to using absolute timeslots for easier theoretical analysis and for time-pacing execution because executing a block does take an max amount of time.