Prime-Mesh Compute Architecture

Abstract

Retium is a prime-driven blockchain that encodes block structure using combinations of natural primes. Early visualizations of blocks show extremely large integers, which could raise concerns about integer overflow, computational complexity, and long-term scalability.

However, Retium does NOT store or manipulate huge integers in runtime.
Instead, Retium uses:

u32 for prime factors
u64 for compact block IDs
BLAKE3 hashing for identity & commitment
Merkle roots for structural integrity
Vectors of primes (Vec<u32>) for logic

The giant numbers seen in the UI are purely decorative and produced by the Explorer for humans, not by the blockchain engine.

This paper explains the mathematical and technical guarantees ensuring that Retium remains safe, scalable, and efficient for millions of ticks—even beyond cosmological timescales.

1. Prime-Based Block Model

Each Retium block is defined by a set of primes, selected according to deterministic linking rules.

Example prime sets in early ticks:

[2, 3, 5]

[5, 7, 11]

[2, 13, 19]

Higher ticks include other primes:

Prime #1 = 2
Prime #100 = 541
Prime #1,000 = 7,919
Prime #1,000,000 = 15,485,863
Prime #10,000,000 = 179,424,673

Even at tick = 10,000,000, the new prime is only 9 digits, well within u32 range.

2. Runtime Block Representation

Retium never stores the composite number (product of primes).
Instead, a block internally looks like:

struct Block {

id: u64, // compact, hashed ID

primes: Vec<u32>, // prime factor set

parents: Vec<u64>, // compact parent links

merkle_root: [u8; 32], // cryptographic state

status: BlockStatus,

tick: u64,

}

Key Guarantees:

id is always a u64 (8 bytes)
primes are integers like 2, 3, 5, 541, 7919 etc. → always fit in u32
merkle_root is fixed-size → never grows
no big integers exist anywhere in the node

3. How Block IDs Are Actually Created

Step 1 — Convert prime list to bytes

primes = [2, 3, 5, 7, 11, 13]

bytes = serialize(primes)

Step 2 — Hash it with BLAKE3

hash = blake3(bytes)

Step 3 — Take first 8 bytes as block ID

id = u64::from_le_bytes(hash[0..8])

✔ Always a 64-bit number
✔ Fast
✔ Impossible to overflow
✔ Collisions astronomically unlikely

This is the true block ID inside Retium.

4. Why Explorer Shows Huge Numbers

Explorer’s job is to help humans visualize the math.

So instead of showing:

Block #9238172323891234

Prime set: [2,3,5,7]

…it sometimes shows:

Block ID = 2 × 3 × 5 × 7 × 11 × 13 × 17 = 510510

This extremely large composite is:

NEVER stored
NEVER used in consensus
NEVER computed by Keepers
NEVER transmitted
NEVER part of block hashing

It is only for human display, produced by Explorer's JavaScript using BigInt.

If you delete the entire giant-number display code,
the blockchain continues working identically.

5. Keeper Computation: What It Actually Does

Keepers DO NOT compute:

10⁵⁰
10¹⁰⁰
10²⁰⁰
or any multi-hundred-digit composite number

Keepers DO compute:

combinations of primes (u32)
atomic uniqueness checks
parent flattening
hashing of small vectors
building Merkle structures
generating deterministic tick plans

Their CPU load comes from:

combinatorics
hash operations
vector comparisons
set logic

NOT from giant integer arithmetic.

6. Why Retium Never Reaches “Dangerous Prime Sizes”

Mathematically impossible.

Size of the Nth prime:

pₙ ≈ n log n

This grows slowly.

Examples:

Tick (n)	Approx Prime (pₙ)	Digits
10⁶	~15,485,863	8 digits
10⁷	~179,424,673	9 digits
10⁹	~21,603,383,497	11 digits
10¹²	~27,631,021,760,000	14 digits
10²¹	~4.8 × 10²²	23 digits

Even at n = 10²¹

(practically impossible to reach in the life of the universe)
the prime is 23 digits — not hundreds, not thousands.

This means:

u64 is sufficient for ticks for millions/billions of years
prime factoring stays cheap
Keeper logic stays stable forever

7. Why Retium Is Mathematically Safe

✔ No big integers in runtime

All internal values remain small:

primes: u32
ids: u64
hashes: 32 bytes
parent lists: Vec<u64>

✔ No overflow risk

Because composite numbers are never computed.

✔ No memory explosion

Primes stay small; vectors stay compact.

✔ No computational explosion

Hashing and set operations remain constant-time relative to vector length.

✔ No need for big-integer libraries

Retium never touches arbitrary-precision math.

✔ Future-proof

Even with trillions of ticks, primes remain < 20 digits.

8. Why Big Human-Visible Numbers Are Harmless

Explorer takes a prime vector:

[2,3,5,7,11]

and shows:

2 × 3 × 5 × 7 × 11 = 2310

Or, for larger sets:

13 × 19 × 23 × 29 × 31 × 37 × 41 × 43 × 47 × 53 × ... = HUGE_NUMBER

But this multiplication happens ONLY:

in UI
in JavaScript BigInt
for visualization

The blockchain engine never sees these numbers.

9. Proof That Giant Numbers Never Enter the Engine

✔ No struct field exists to store a big integer

Block has no BigInt, no big-number type at all.

✔ Everything is serialized as small values

Borsh/JSON only encode u32/u64 and byte arrays.

✔ Keeper factorization works on u64

Impossible with thousand-digit numbers.

✔ Merkle trees accept bytes, not integers

They hash small input sizes.

✔ Deleting the Explorer’s “big number display” does not affect consensus

Block IDs remain hashes.

10. Conclusion

Retium’s prime-mesh architecture is fundamentally safe because:

Runtime = small primes + small hashes
UI = optional giant numbers
No big-integer arithmetic ever enters consensus
Primes remain tiny even at astronomical tick counts
u64 IDs and u32 primes are sufficient for millions of years of operation

The giant block numbers in Explorer are an illusion made for humans —
not part of the actual blockchain.

Retium is, mathematically and computationally, future-proof.