Reduce slot time to 90s

MIPs (Mina Improvement Proposals)
21

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.

22

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
23

@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:

  1. slot time = X, slot constant = 1
  2. 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
24

Hi Matej, thanks for proposing this idea! I’ve thought about it, and here’s what I think:

1. Technical Merit of the Idea

The slotConstant concept is technically solid and tackles a real pain point in zkApp development. Your proposed mechanism makes a lot of sense:

  • slot time = X, slot constant = 1 (initial state)

  • slot time = X/2, slot constant = 2 (post-hardfork)

  • calculation: slotTime * slotConstant (keeps IRL time consistent)

This would give zkApp developers clean semantics for time-dependent apps and let them automatically adjust to slot time changes without having to manually tweak their code.

2. Current Necessity Assessment

The idea has merit, but it’s not critically necessary right now for a couple of reasons:

Existing Redeployment Requirements: zkApp developers already need to redeploy their applications on pretty much any protocol change. During hardforks, developers are already going through:

  • Recompiling their zkApps

  • Redeploying verification keys

  • Updating any logic affected by protocol changes

Since this workflow already exists, developers can handle slot time changes through explicit code updates during the mandatory redeployment process.

Developer Experience Impact: Sure, the slotConstant would be convenient by cutting down on manual edits during hardforks, but it’s a relatively small improvement considering all the other redeployment work that’s already required.

3. Implementation Timeline Considerations

Current Hardfork Scope: This feature can’t make it into the upcoming hardfork because:

  • The scope is already pretty substantial and locked in

  • Adding more features would push back the hardfork timeline

  • The feature isn’t critical for protocol security

Future Consideration: The proposal could definitely be looked at for future hardforks if:

  • It goes through the full MIP (Mina Improvement Proposal) process

  • There’s clear developer demand for it or it’s part of a larger block of changes targeting smoother experience of maintaining zkApps over the hardfork transitions

Recommendation

Worth documenting this as a formal MIP for future consideration. While it’s not urgent, it shows thoughtful protocol design that could benefit the ecosystem when we have bandwidth for non-critical improvements.

25

Actually, let me add a follow-up thought to this - I think there might be an even simpler way to handle this that doesn’t require any protocol changes at all.

What if we implement the slotConstant entirely at the zkApps library level? Here’s how it could work:

The constant would just be hard-coded somewhere in the zkApps framework itself. Since we already ship new versions of the zkApps framework with every hardfork, we could simply update this constant in each new release:

  • Pre-hardfork: zkApps V{n}.x ships with slotConstant = 1

  • Post-hardfork: zkApps V{n+1}.x ships with slotConstant = 2

The beauty of this approach is that developers who write their applications using the slotConstant wouldn’t need to change their actual application code when they recompile for a hardfork. They’d just recompile against the new framework version, and their zkApp would automatically pick up the updated constant.

This would be tremendously easier to implement since it doesn’t touch the protocol at all - it’s purely a framework-level feature. Plus, it still gives developers the clean semantics and automatic adjustment you were looking for, without any of the protocol complexity.

What do you think about this library-level approach?

26

:ledger: As of Sept 2, this MIP has completed community discussion and is now in the Finalization stage. That means all feedback so far has been addressed, consensus is positive, and the proposal is ready for inclusion in the upcoming hard fork, pending the community’s on-chain vote.

However, further discussion is always welcome and encouraged. It just won’t influence readiness for the OCV process, unless something critical comes up.

1 Like