PureOne's picture
HVCE v4.0.0 OmniCrown — very early public research prototype
0081600 verified
|
Raw
History Blame Contribute Delete
5.06 kB

HVCE v4 Algorithm

Core name

Proof-Carrying Omni-State Compression

HVCE v4 is not one compressor. It is a verified portfolio machine. For every block or microgroup it searches a finite menu of reversible descriptions and stores the smallest exact proof-carrying representation.

A representation is accepted only when it can be decoded deterministically and the decoded bytes match the stored SHA-256 digest.

Archive-level pipeline

input tree
  -> safe path normalization
  -> metadata capture
  -> small-file solid micro-pack
  -> content-defined chunking for large files
  -> exact duplicate detection
  -> near-duplicate sparse XOR patch search
  -> per-unit representation search
  -> payload assembly
  -> compact compressed manifest
  -> optional whole-archive password envelope
  -> optional GF(256) recovery tail

Compression branches

1. Entropy-respect classifier

HVCE samples each unit and estimates byte entropy. If the unit looks random, encrypted, or already compressed, v4 skips expensive symbolic modeling. This directly fixes the usual failure mode where a research compressor wastes time trying to compress entropy-saturated inputs.

For random/high-entropy blocks the strongest correct behavior is:

store raw, dedupe if repeated, patch if near-duplicate, verify, optionally encrypt/recover

It is not mathematically legitimate to promise universal shrinkage on truly random data.

2. SPWSE / world-state recipes

Exact recipes include:

  • recipe_constant: one repeated byte.
  • recipe_periodic: one finite period repeated to length n.
  • recipe_sparse_zlib: dominant background byte plus sparse defects.
  • recipe_rle_zlib: run-length stream compressed by zlib.
  • recipe_polyword: exact finite-difference polynomial streams over 8/16/32/64-bit little-endian words, degree ≤ 3.
  • recipe_rank1_2d8_zlib: separable 2D byte field row[y] + col[x] mod 256 plus sparse exact defects.

This is the main “world-state” idea: do not encode the observations when a compact deterministic state generator plus residuals is shorter.

3. Nanophotonic/vector transforms

Transforms are reversible bases that expose lower entropy to standard codecs:

  • delta8
  • delta16le
  • delta32le
  • bitplane
  • nibbleplane
  • neural4

Each transform is followed by a conventional backend such as zlib, bz2, or lzma. The decoder reverses the stack in the opposite order.

4. Causal neural residual branch

neural4 is a deterministic integer predictor. It uses four prior bytes, bounded integer weights, and an online update rule. It stores residual bytes, not a neural model file. This preserves exact decoding and avoids hidden side information.

5. Cross-file archive-state branch

HVCE keeps a bounded cache of prior decoded chunks by length. A new chunk can be stored as:

reference chunk id + sparse XOR defects

This is especially relevant for versioned media, model checkpoints, game assets, incremental backups, and repeated encrypted-looking payloads. The byte stream may look incompressible locally, yet the archive as a world-state object may contain obvious temporal redundancy.

6. Solid micro-pack branch

Many ordinary office folders contain hundreds or thousands of tiny files. Ordinary ZIP stores each member separately and pays repeated headers and dictionary resets. HVCE v4 packs low-entropy tiny files into solid microgroups before compression. Individual file boundaries are preserved by manifest offsets.

7. Header compression

The manifest is compressed with whichever of zlib-9 or lzma-extreme is smaller. Encrypted archives hide the whole manifest, including names and directory structure.

8. Password envelope

Password mode uses:

PBKDF2-HMAC-SHA256(password, salt, iterations) -> 64 bytes
first 32 bytes  -> ChaCha20 encryption key
second 32 bytes -> HMAC-SHA256 authentication key

The whole private header and payload are encrypted and authenticated. Extraction verifies the HMAC before decryption.

9. Recovery records

The optional recovery tail uses two parity equations over GF(256):

P0 = xor(shard_i)
P1 = xor((i+1) * shard_i)

Given shard hashes, HVCE can detect corrupted shards and recover up to two corrupted shards when the archive length is unchanged and the recovery tail is intact.

This is not a full replacement for external backups. It is a practical archive-integrity layer comparable in spirit to recovery records in mature archive tools.

Complexity

Let N be input bytes and B be block size.

  • Fast profile: near-linear in N, with early entropy gates.
  • Balanced profile: linear plus portfolio trials on compressible blocks.
  • Max profile: more exhaustive transform/codec search and should be used for release archives, not hot paths.

Decode contract

The decoder requires only:

  • Python standard library;
  • the .hvce file;
  • password if encrypted.

No hidden model, internet access, external dictionary, or hardware-specific side information is required.