Why not double the number of slots? Thus, leaving the same duration of the epoch.
I’m talking about doubling the number of slots in an era to keep the real world era length constant.
Thank you for the suggestion about doubling the slot count while maintaining constant epoch duration. While this approach would preserve certain operational expectations around delegation transactions and block production patterns, there are several important considerations that make simply reducing slot time the preferred approach:
Security Benefits of Shorter Real-World Epochs From a security perspective, shorter epochs in real-world time are inherently better for the protocol. The core issue is the attack window created by ledger locking - since we lock ledgers two epochs in advance, there’s always a theoretical vulnerability where someone could sell their Mina but still retain staking power according to the previous ledger. While Ouroboros has robust protections against such attacks and they’re unlikely to succeed in practice, minimizing this temporal window by shortening epoch duration provides an additional security layer.
Protocol Parameter Complexity The Ouroboros Samasika consensus protocol has numerous interdependent security parameters, and the number of slots per epoch is one of them. Any change to slot count would require careful security analysis to ensure we’re not inadvertently weakening the protocol’s guarantees. While such an adjustment would likely be safe, it introduces unnecessary complexity and risk.
Simplicity of Slot Time Adjustment In contrast, adjusting slot duration is much more straightforward from a security standpoint. Ouroboros is designed to be agnostic to real-world slot timing - the protocol’s security properties don’t depend on whether a slot lasts 3 minutes or 1.5 minutes. This makes slot time reduction a cleaner, lower-risk approach that achieves our goals without requiring extensive security re-evaluation of core consensus parameters.
2 Likes
@georgeee would it make sense to introduce a slotConstant to the zkapps protocol, in order to enable “constant IRL time” zkapps? I’m thinking of the following scenario - slot time is X, and a zkapp is implemented to have a “time” dependency based on slots (better than blocks/length?), now a hard fork happens changing slot time to X/2 (2x fast), now the zkapp’s time dependency is half also, which might not be ideal. If the protocol had a slotConstant which could be used as an anchor to prepare for changing slot times down the line, it could work as follows:
- slot time = X, slot constant = 1
- hardfork → slot time = x/2, slot constant = 2
This way the zkapp could calculate its time dependency like slotTime * slotConstant and you’d arrive at the same “IRL time” in the end?
Excuse me if I made any mistakes here but I think the gist of the idea is there. wdyt?
1 Like