Norsh
HomeNTPNCLAPI
HomeNTPNCLAPI
  1. Published
  • Norsh
    • Usage Guide
      • Cryptographic Identity
    • API
      • Crypto
        • Generates a public and private key pair
        • Generates an address from a public key.
  • NTP - Norsh Technical Paper
    • LICENSE-NCL-11
    • Published
      • NTP-1: Norsh Technical Paper Specification
      • NTP-2: Standards for Encoding, Time and Localization
      • NTP-3: Cryptography and Hash Specification
      • NTP-4: Interchangeable Data Standard
      • NTP-5: Temporal Time-Step Model
      • NTP-6: Modular Prime Fragmentation
      • NTP-7: The End of Mining - PoW
      • NTP-8: The Fallacy of Stake - PoS
      • NTP-9: The Myth of Absolute Non-Censorship
      • NTP-10: Structural Failures of Decentralization
  • NCL - Norsh Commons License
    • NCL-0: Norsh Commons License
    • NCL-1: Attribution Requirement
    • NCL-2: Restricted Commercialization
    • NCL-4: Commercialization with Agreement or Royalties
    • NCL-8: Educational Use Permission
    • NCL-16: Complementary Use and Integration Permission
    • NCL-32: Pre-Approval for Application Publication
    • NCL-64: Restricted or Authorized Derivatives
    • NCL-128: Contribution Terms
  1. Published

NTP-5: Temporal Time-Step Model

Status: PUBLISHED
Authors: Danthur Lice
Date of Creation: 2025-01-16
Date of Publication: 2025-02-02
References: RFC 6238
License: NCL-11

1. Scope#

This document establishes the temporal fragmentation model adopted by the Norsh ecosystem. The model segments time into fixed, non-overlapping intervals referred to as time-steps, each identified by an integer value derived from epoch time. The model provides deterministic alignment across distributed modules without requiring clock synchronization or inter-node negotiation. It is applicable to operations involving block generation, ledger partitioning, cache invalidation, distributed scheduling, and fragment-based lookup.

2. Normative Principles#

Time fragmentation must be strictly deterministic, reproducible, and architecture-independent. All subsystems that rely on time-sensitive processing must adopt a consistent interval definition to preserve interoperability and modular isolation.
The existence of temporal windows is not arbitrary; it is a technical necessity for:
Ensuring synchronization without communication.
Achieving sharding determinism.
Structuring batch processing cycles.
Allowing backward and forward computation of time windows using only the epoch timestamp.
Time-step boundaries are immutable and non-adjustable post-calculation.

3. Preconditions and Scope Constraints#

This model assumes:
Time is expressed in UTC, using the Unix Epoch (1970-01-01T00:00:00.000Z) as reference.
All systems involved have access to a millisecond-resolution clock source.
The interval definition is globally agreed and fixed per application.
Transition between time-steps must not carry state implicitly.

4. Technical Specification#

4.1 Fragment Calculation#

Time is segmented by the following formula:
FragmentID=⌊Interval(ms)CurrentTime(ms)​⌋
CurrentTime: Current UTC time in milliseconds since epoch.
Interval: Fragment size in milliseconds (e.g., 360,000 for 6 minutes).
Rounding: Always floor to ensure boundary alignment.

4.2 Valid Intervals#

Intervals must be technically justified and defined in milliseconds. Examples include:
IntervalDurationUse Case
360,0006 minutesBlock segmentation
1,0001 secondHigh-frequency batching
604,800,0001 weekPeriodic reporting
No floating or adaptive interval model is permitted under this specification.

4.3 Applications#

The Temporal Time-Step Model is applicable to all contexts requiring deterministic segmentation of time. Typical implementations within the Norsh ecosystem include:
TOTP and Time-Based Codes: Time-step alignment guarantees the cryptographic validity of time-based one-time passwords (e.g., per RFC 6238) and other mechanisms that depend on temporal coherence.
Block Production: Each block must be generated within a distinct time fragment, without overlap across interval boundaries.
Ledger Partitioning: Ledger shards are indexed and bounded by the time fragment in which data is recorded, enabling distributed storage and parallelized processing.
Temporal Indexing: Caching systems, memory layers, and file structures must use the fragment ID as a deterministic key for efficient lookup, consistency enforcement, and historical traceability.
All subsystems that execute time-sensitive or stateful logic must implement fragment-based control to guarantee modularity, reproducibility, and long-term observability.

4.4. Implementation Guidelines#

To ensure consistency:
Fragment Calculation Logic must be pure and side-effect free.
Time Source must have millisecond precision or better.
Rollover Events (from one fragment to the next) must be explicitly managed.
Fragment ID should be persistently stored when recording fragment-bound operations.
Sub-second Fragmentation is permissible only if nanosecond resolution is guaranteed and justified by the domain.

5. References#

RFC 6238: TOTP: Time-Based One-Time Password Algorithm
https://datatracker.ietf.org/doc/html/rfc6238

6. Conclusion#

The Time-Step Model formalized in this specification is a foundational mechanism for distributed coordination in the Norsh ecosystem. Its adoption enables deterministic behavior across independently executing modules and eliminates the need for active synchronization. The model provides a scalable, architecture-neutral method to encode temporal logic, enabling consistent block creation, data segmentation, and transaction isolation across systems. Any derivation from this model must be explicitly defined and documented in a higher-level NTP.
Modified at 2025-05-29 16:25:01
Previous
NTP-4: Interchangeable Data Standard
Next
NTP-6: Modular Prime Fragmentation
Built with