Offline operators with significant stake cause bundle production to slow down due to these operators “ignoring” the election.
Unlike Ethereum operators, Subspace does not have a deterministic on-chain way to tell whether an operator is offline because our VRF election is based on the private VRF signature and only the winner himself knows they were elected before producing a bundle and therefore proving the win to others. Therefore we cannot slash operators for being offline.
With the following, I introduce a heuristic mitigation based on Stability (example):
An operator should be marked inactive in the domains operator registry when some MaxMissedEpochs have passed with no bundles produced by this validator and their stake should not participate in the following epochs VRF elections (MaxMissedEpochs based on their stake; algorithm, and proposed parameters here), they will be considered offline using a new field in OperatorRegistry here, and their stake will not participate in the VRF elections.
If they return, they must submit a new extrinsic add_operator_again and will be reinstated at the next epoch transition.
This “offline” status is different and softer than “frozen” because nominators can still withdraw from the operator’s pool, and it does not remove the operator from the registry and trigger withdrawal to all nominators.
One issue with this approach is that in case an operator never comes back online their entry will occupy space in OperatorRegistry forever.
One mitigation to this is to introduce a minimal charge for a spot in OperatorRegistry. This can be a small fee payable to the protocol fund or burnt, deducted from the operator stake every epoch for every operator in the registry. The fee can go up exponentially if operator was offline for a significant number of epochs until their stake goes below MinStake and triggers deregistration.
Another issue, as raised by @ning is that the original approach in the post assumes there are always transactions to fill bundles and if not, makes use of so-called “empty bundles”: when there are no transactions available, an operator will produce an empty bundle anyway. However, we would like to avoid that as empty bundles take up blockspace.
He suggests the Substrate im_online pallet: where an operator can send a transaction every session to signal their online presence.
One way we could use this is to make every operator send such a transaction every epoch. However, that will result in a large number of transactions and still does not “punish” malicious operators for not producing bundles.
Another way is we can follow the original algorithm, but in cases where there are no transactions available to bundle an operator will send this im_online extrinsic.