aura/slot_based: Reduce authoring duration of the last produced block

[lexnv]

This PR adjusts the block authoring to stop producing blocks 1 second before the scheduled slot change.
This introduces a safety buffer to prevent blocks from being authored too late for inclusion.

• 2s blocks / 3 cores: The authoring duration of the last block is reduced from 2s to 1s.
• 500ms blocks / 12 cores: The authoring duration cannot be reduced past 500ms, therefore the last two blocks are no longer authored

Testing Done

Tested on top of:

• ah-westend: Elastic Scaling with 3 cores on AssetHub Westend #9880

3 cores 2s blocks

aura::cumulus: [Parachain] Adjusting authoring duration for slot. authoring_duration=2s duration=1.987s last_reported_slot=Some(Slot(293723040)) next_slot=Slot(293723040) next_duration_change=5.987s next_slot_change=Slot(293723041)
aura::cumulus: [Parachain] Adjusted proposal duration. duration=Some(1.987s)

aura::cumulus: [Parachain] Adjusting authoring duration for slot. authoring_duration=2s duration=1.991s last_reported_slot=Some(Slot(293723040)) next_slot=Slot(293723040) next_duration_change=3.991s next_slot_change=Slot(293723041)
aura::cumulus: [Parachain] Adjusted proposal duration. duration=Some(1.991s)

aura::cumulus: [Parachain] Adjusting authoring duration for slot. authoring_duration=2s duration=1.99s last_reported_slot=Some(Slot(293723040)) next_slot=Slot(293723041) next_duration_change=1.99s next_slot_change=Slot(293723041)
aura::cumulus: [Parachain] Adjusted proposal duration. duration=Some(990ms)

12 cores 500ms blocks

aura::cumulus: [Parachain] Adjusting authoring duration for slot. authoring_duration=2s duration=494ms last_reported_slot=Some(Slot(293724134)) next_slot=Slot(293724134) next_duration_change=1.494s next_slot_change=Slot(293724135) deadline=494ms
aura::cumulus: [Parachain] Adjusted proposal duration. duration=Some(494ms)

aura::cumulus: [Parachain] Adjusting authoring duration for slot. authoring_duration=2s duration=493ms last_reported_slot=Some(Slot(293724134)) next_slot=Slot(293724134) next_duration_change=993ms next_slot_change=Slot(293724135) deadline=0ns
aura::cumulus: [Parachain] Not enough time left in the slot to adjust authoring duration. Skipping block production for the slot. next_duration_change=993ms next_slot_change=Slot(293724135)
aura::cumulus: [Parachain] Adjusted proposal duration. duration=None
aura::cumulus: [Parachain] Not building block due to insufficient authoring duration

aura::cumulus: [Parachain] Adjusting authoring duration for slot. authoring_duration=2s duration=494ms last_reported_slot=Some(Slot(293724136)) next_slot=Slot(293724137) next_duration_change=494ms next_slot_change=Slot(293724137) deadline=0ns
aura::cumulus: [Parachain] Not enough time left in the slot to adjust authoring duration. Skipping block production for the slot. next_duration_change=494ms next_slot_change=Slot(293724137)
aura::cumulus: [Parachain] Adjusted proposal duration. duration=None
aura::cumulus: [Parachain] Not building block due to insufficient authoring duration

Part of: #9848

[lexnv]

/cmd prdoc --audience node_dev --bump patch

[sandreim]

This will not always work if we skip building some block. Since we know the block production interval, we can easily compute the time index when the last block production begins.

[bkchr]

You can have slots that are longer than one relay chain slot.

[lexnv]

@sandreim Let me know if I interpreted correctly the #10154 (comment) 🙏

For 3 cores, this removes the wrong reliance on the relay slot duration and produces the desired output:

// First block
Adjusted proposal duration. duration=1.987s

// Second block
Adjusted proposal duration. duration=1.992s

// Last block
Adjusted the last block production attempt for the slot. last_reported_slot=Slot(293653272) next_slot=Slot(293653273) authoring_duration=1.488s
Adjusted proposal duration. duration=1.488s

[sandreim]

Yeah, but I don't think this works in practice if blocks are fuller. If you have a 1.5s block, even if let's say there isn't much latency, say 50ms to the next guy, this means that after the announcement it takes 150ms to fetch it and another 1500ms to execute, assuming ref hw. So the next guy would have been already built it's own block at same height.

[sandreim]

But that is worst case scenario (full blocks). Otherwise I'd cut it to 1s just to leave more room for latency.

Happy to hear some more opinions on how much a safe cut should be.

[sandreim]

This does not work for 500ms blocks. Shouldn't this actually be computed based on some average expected latency ?

[sandreim]

Lets consider the case of 500ms blocks (be it ES or @bkchr blocks). Let's say we'd have an authorship duration for last block in slot of just 50ms (not possible with this PR) and latency between current author and next author is 200ms. The timeline is as follows:

• last block X production at height N begins at T
• block is announced at T + 50ms
• next guy receives announcement and requests the block at T + 250ms
• author receives the request at T + 450ms
• next guy begins producing it's first block Y of the slot at height N at T + 500ms
• next guy receives block X at T + 650ms

So this won't really work because it takes 3 x latency to even receive the block . I think we should consider reducing authoring over a larger period of time to account for the latency and maximum weight of the last block authored in a slot.

For the example above not building any blocks in the last 1s of the slot would do it.

@skunert WDYT ?

[lexnv]

Yep, this makes sense to me! Since we can have quite large ~250ms latencies, the last 1s should be conservative enough to capture most cases 🙏

Have adjusted the code a bit to skip building the last 1s, relying on the time of the "next slot"

[skunert]

In general the logic looks good, just some pedantic nits :D.

I would like to see some additional test cases in the slot timer tests for this though.

[skunert]

Looks like some logs snuck in here? :D

[skunert]

We should rename time_until_next_slot, because its not really reflecting the next slot, but more the next block timepoint.

[skunert]

Nit: I was thinking whether we can simplify this a bit with less type fiddling. Keeping Duration as much as possible seems to help at least a bit. But it never gets super nice.

Suggested change

	let now = duration_now();
	let now = now.as_millis().saturating_sub(self.time_offset.as_millis());
	let last_reported_slot = self.last_reported_slot.unwrap_or_default();
	let Some(last_slot_timestamp) = last_reported_slot.timestamp(slot_duration) else {
	tracing::error!(target: LOG_TARGET, "Failed to obtain the last slot timestamp");
	return Err(())
	};
	// Compute when the next different slot starts.
	let next_different_slot_time =
	last_slot_timestamp.as_millis() + slot_duration.as_millis() as u64;
	let remaining_millis = next_different_slot_time.saturating_sub(now as u64);
	let next_aura_slot =
	Slot::from_timestamp(Timestamp::from(next_different_slot_time as u64), slot_duration);
	Ok((Duration::from_millis(remaining_millis as u64), next_aura_slot))
	let now = duration_now();
	let now = now.saturating_sub(self.time_offset);
	let last_reported_slot = self.last_reported_slot.unwrap_or_default();
	let next_slot = last_reported_slot + Slot::from(1);
	let Some(next_slot_timestamp) = next_slot.timestamp(slot_duration) else { return Err(()) };
	let remaining_time = next_slot_timestamp.as_duration().saturating_sub(now);
	Ok((remaining_time, next_slot))

[skunert]

Suggested change

	let Ok((next_duration_change, next_slot_change)) =
	let Ok((duration_until_next_slot, next_slot)) =

[skunert]

Suggested change

	let deadline = next_duration_change.saturating_sub(BLOCK_PRODUCTION_ADJUSTMENT_MS);
	let duration_until_deadline = next_duration_change.saturating_sub(BLOCK_PRODUCTION_ADJUSTMENT_MS);

[skunert]

I think we can be more generous and increase BLOCK_PRODUCTION_THRESHOLD_MS to 100ms or something. I introduced the original BLOCK_PRODUCTION_THRESHOLD_MS not because blocks below 500ms are not viable at all, but because I wanted to prevent that someone assigns 36 cores to their chain and we arrives at <200ms blocks. So I chose this arbitrary value that we only produce blocks every 500ms for now.

In our case here, producing a 400ms block is also okay.

[skunert]

For the record, everything here currently assumes that every slot changes brings a different author. Someone could run a single-collator parachain which does not need to respect these offsets. We would break that use-case.