Cardano-node: [FR] - Add CLI command to display the leadership schedule
Describe the feature you'd like
I would like to know my leadership schedule, at least the nearest upcoming leadership event, so I can plan my node maintenance or/and KES rotating.
mmahut
All 23 comments
A summary of recently minted blocks as a part of this information would also be beneficial, similar to what is currently implemented on ITN - with status (in block / failed due to X) as well as epoch/slot and block hash data
cardadad
on 1 Jun 2020
Recent events are available via the JSON logs and aggregates via the metrics.
Getting the future schedule will take a bit more effort. The node does not compute the schedule in advance, it does everything incrementally.
dcoutts
on 2 Jun 2020
This is pretty important for pool operators to know. Without it we cannot know when it's best to do maintenance. We also cannot gauge performance of our pools. If you can get a schedule in advance, you can then evaluate after the fact as to how your node performed on those slots. During ITN, this was a primary way of differentiating how good a pool was on pooltool. Compare their assigned slots to how many blocks they minted. If we solely look backwards at blocks, we don't know whether we just got a random poor slot lottery or if our node is actually under-performing and missing or not propagating blocks properly.
AndrewWestberg
on 4 Jun 2020
Even if we could get a cli command to query when our next slot is, that would be sufficient for the maintenance piece. No need to process the entire leader log. Or even "Do I have a slot in the next 30 minutes?" type of query.
AndrewWestberg
on 4 Jun 2020
It would be nice if it had the same API as Jormungandr so the tools built using those APIs could work with both.
teamstaking
on 14 Jun 2020
I'll throw my $0.02 in here to agree with Andrew's sentiment above. Being able to know if and when you have a block coming up would be extremely helpful from a maintenance/upgrade perspective and help to mitigate a lot of the strategies I'm currently hearing bandied about in public and private channels about how best to accomplish rolling updates (which almost always entail operating two instances of the BP for some simultaneous period).
Crypto2099
on 17 Aug 2020
This is a MUCH needed utility. Could this feature request please be expedited? I am looking for a CLI tool that will output a leader log for the entire epoch, similar to the tool that was available in Jormungandr.
samcgill29
on 17 Aug 2020
Second this request. I have a pool which should be producing blocks, but so far isn't even though all prometheus (Cardano-node) stats look good. How do I tell whether it's just been bad luck - no slots assigned, versus some fault in configuration or upstream network issue that I am not aware of? This would be a great starting point to diagnose.
cyber-russ
on 20 Aug 2020
Adding another comment to this one to keep it on everyone's radar. This is my very top #1 desired thing to have as a SPO. Without it, we cannot track our real performance or plan maintenance without potential injury to our pool or delegation. For SPOs living on the edge where every block counts, this is critical.
AndrewWestberg
on 1 Sep 2020
@Jimbo4350 Can we get an update on the status of this FR, please?
samcgill29
on 1 Sep 2020
@vhulchenko-iohk do we have any updates on this FR?
mrbrinker
on 7 Sep 2020
I have cracked the nut and will be adding this functionality to an upcoming version of JorManager.
JorManager Telegram: https://t.me/jormanager
I have been sharing my knowledge with other developers in the community. They have confirmed that they are working on a Python version, a javascript version, and a GO version. They will be released to the SPO community once complete as well.
This discussion is happening in this group if you want to follow along: https://t.me/joinchat/OKP2Okapw5FrZXBPGtadIQ
AndrewWestberg
on 5 Oct 2020
Smart work and good that this has been disclosed but I am strongly against this as it opens SPOs up to a whole class of DDoS attacks against the network. Once you know slot leader you can attack their relays easily based on publicly accessible knowledge. This needs to be fixed fast in the node to stop this capability.
It also allows SPOs to game and only be online for slots which weakens the overall network and its processing capabilities.
cyber-russ
on 5 Oct 2020
Smart work and good that this has been disclosed but I am strongly against this as it opens SPOs up to a whole class of DDoS attacks against the network. Once you know slot leader you can attack their relays easily based on publicly accessible knowledge. This needs to be fixed fast in the node to stop this capability.
It also allows SPOs to game and only be online for slots which weakens the overall network and its processing capabilities.
As I understand it, currently, the VRF/KES of the pool in question is required to calculate the slot leadership schedule for that pool. So this is a far way if not impossible from telling us the slot leadership schedule of other parties (and thereby allowing us to target them).
Crypto2099
on 5 Oct 2020
I have cracked the nut and will be adding this functionality to an upcoming version of JorManager.
JorManager Telegram: https://t.me/jormanager
I have been sharing my knowledge with other developers in the community. They have confirmed that they are working on a Python version, a javascript version, and a GO version. They will be released to the SPO community once complete as well.
This discussion is happening in this group if you want to follow along: https://t.me/joinchat/OKP2Okapw5FrZXBPGtadIQ
Do you have a functional and technical specification for the feature? I have a developer to implement it directly into the Cardano Node codebase...
mark-stopka
on 6 Oct 2020
If that's correct then its good news that this requires the KES/VRF as that makes a fix less urgent.
I would attack this way instead. Sybil attack- register a LOT (thousands) of pools, I only need my pool to be available for its one slot (I'm not going to put much delegation against any pool, as I get to know what pools will be successful that Epoch), and I don't need much resource as I use the same relays and just switch in and out on the core node for the pool that will be successful.
Law of unintended consequences applies here. You are changing fundamental security tenets of the system which is that slot leaders are elected with a provably random algorithm in a previous Epoch. Once you know the slots there is no random.
cyber-russ
on 6 Oct 2020
I don't quite understand that attack scenario. Registering thousands of pools will cost you 500 ADA per pool. Then putting in sufficient stake per pool to even get assigned one block per epoch even more and re-using stake across other pools will have a delay of 2 epochs
rene84
on 6 Oct 2020
Rene, perhaps I鈥檓 wrong on the attacks, I haven鈥檛 worked through the numbers. But Cardano aspires to be the worlds financial operating system it won鈥檛 be if SPOs can game it like this...
cyber-russ
on 6 Oct 2020
Rene, perhaps I鈥檓 wrong on the attacks, I haven鈥檛 worked through the numbers. But Cardano aspires to be the worlds financial operating system it won鈥檛 be if SPOs can game it like this...
You think you are preventing something when it is implementable by an attacked but not just implemented? You are not... honesty of 51% stake is a Ouroboros security assumption, if violated, it is not provably secure, period.
mark-stopka
on 6 Oct 2020
@cyber-russ This is not gaming the system at all, the security prerequisite is that only the SPOs are allowed to know if they are going to make a block - mainly to prevent DDOs from other SPOs - and this is not violated since the data required to know that has always been available (it's how the node itself knows if it has to make a block), there is just currently no implementation to test for future blocks, probably because it's just a convenience feature and is not a priority for IOG.
2072
on 7 Oct 2020
For those who happen across this issue ticket, here are some links to the community-based projects that allow you to see leader logs.
JorManager:
https://bitbucket.org/muamw10/jormanager
Python:
https://github.com/papacarp/pooltool.io/tree/master/leaderLogs
NodeJS:
https://github.com/MarcelKlammer/cardano-leader-logs
AndrewWestberg
on 10 Oct 2020
CNCLI contains an implementation built in RUST.
AndrewWestberg
on 20 Nov 2020
This issue can probably be closed out.
AndrewWestberg
on 20 Nov 2020
Related issues
bergr01
路
8Comments
dorin100
路
3Comments
aftershowrc
路
3Comments
deepfire
路
5Comments
dmitrystas
路
6Comments
Most helpful comment
This is pretty important for pool operators to know. Without it we cannot know when it's best to do maintenance. We also cannot gauge performance of our pools. If you can get a schedule in advance, you can then evaluate after the fact as to how your node performed on those slots. During ITN, this was a primary way of differentiating how good a pool was on pooltool. Compare their assigned slots to how many blocks they minted. If we solely look backwards at blocks, we don't know whether we just got a random poor slot lottery or if our node is actually under-performing and missing or not propagating blocks properly.