UpcomingLeader sysvar

[cavemanloverboy]

Motivation

I was just about done writing a leader schedule program as a public good, and then realized it's an incredibly stupid idea to pass around one or two >1MB accounts just to find out who the next leader is. This information is needed for market makers to be able to update quotes based on swaps coming in on specific leaders (e.g. leader is malicious, very remote, or has historically unreliable scheduling characteristics).

Proposal

The runtime maintains and exposes a sysvar

#[repr(C)]
pub struct UpcomingLeader {
    current_slot: u64,
    current_leader: Pubkey,
    next_leader_slot: u64,
    next_leader: Pubkey,
}

that contains everything a program needs to be able to adjust quotes based on current and next leader. next leader here mostly to future proof, in case someone finds a use for it, but not as useful as current leader. current slot is here so that program is not required to also load in clock sysvar. This could be expanded and treated as a ClockV2 sysvar if we want

[cavemanloverboy]

probably want to use vote account for this, tbh.

[maurodelazeri]

yeah this is very helpful I was literally doing the same, very much agree with this

[deanmlittle]

It's better to just grab the slot of the current Clock and use that with the existing sol_get_sysvar syscall on the leader schedule account imo. Far more flexible, no per-slot update and no need to verify the sysvar address in the VM.

[cavemanloverboy]

this feels like an impl detail imo

[deanmlittle]

I'm just saying you don't necessarily need to go and implement "UpcomingLeader111111111" which has to update on each slot boundary for fear of throwing around a large account that is only updated once per epoch. If you do "LeaderSchedu1e111111111111" instead, and list the current and next epoch in there, you can calculate the offset of the current and incoming leader based upon Clock.slot and fetch with sol_get_sysvar. Despite costing slightly more in CUs, it's actually much faster in wall clock terms, and the costs will hopefully be better aligned by the time this lands.

[deanmlittle]

Iirc, @buffalojoec actually built sol_get_sysvar for accessing the SlotHashes sysvar account for this very use case.

[buffalojoec]

We bult sol_get_sysvar for the ALT and Stake programs' time delay functions, the former using SlotHashes and the latter using StakeHistory.

I do agree, though, why not just put the whole leader schedule in the sysvar?

[cavemanloverboy]

takes more cus to calculate offset into this ptr than to just read next leader from const offset lol

[leafaar]

I feel it would be a good idea trying to merge these two discussions: #511

[leafaar]

cc @sam0x17

[sam0x17]

agreed @cavemanloverboy would be great if you could look at #511, it is basically ready to move forward let me see if I can update it