Every chain uses the account as its unit of state.
That is a granularity error.
LOGOS-Σ uses an occupation cell instead. Three things still treated as separate unsolved problems — state bloat, hot shards, expensive state-root updates — turn out to be three consequences of that one choice, and three measurable quantities of the same partition function.
versus a twenty-level Merkle SHA-256 path — and byte-exact after 20 000 consecutive updates.
cell-granular sharding with Gibbs routing, against account plus uniform hash as deployed today.
with a measured cause rather than an assumption: 62.49 % of calldata bytes are ABI padding 0x00.
01 · Diagnosis
Three symptoms, one cause
They are not independent. They all follow from picking the wrong unit of storage.
Redundancy between accounts is never merged, because the account is the unit. Two identical contracts still occupy space twice.
All sharding splits by address. One hot contract locks an entire shard — and no routing algorithm can split an indivisible key.
Every write rehashes roughly twenty Merkle levels, because the hash function is deliberately nonlinear. That is a theorem, not an engineering choice.
02 · Measurement · sharding
One algorithm, two granularities
Routing 8 131 real contract calls onto 64 shards. The top 10 % of contracts carry 70.66 % of the load — real skew, not constructed.
| Unit | Routing | Hottest shard load | vs ideal |
|---|---|---|---|
| account | uniform hash — the status quo | 2 587 | 20.36× |
| account | Gibbs occupation | 2 513 | 19.78× |
| cell | uniform hash | 160 | 1.26× |
| cell | Gibbs occupation | 133 | 1.047× |
Smart routing at account granularity bought 1.03×, which is nothing. We keep that number because it is the valuable part: the single hottest contract alone carries 30.9 % of the load, that is 19.8 times the average per-shard load. No algorithm can subdivide an indivisible key — this is a lower bound, not a defect in the implementation.
The broader consequence: every "smarter sharding" claim made by an account-based chain runs into exactly this same wall.
Change the unit to a cell and the same algorithm pulls 20.36× down to 1.047× of ideal. The 19.45× decomposes honestly: 16.2× comes from the granularity change and only 1.20× from Gibbs routing. Anyone selling this architecture on the phrase "smarter routing" is selling the wrong part — and our own specification forbids attributing the gain that way. It is also why another chain cannot copy this without replacing its state model.
03 · Measurement · state commitment
A state root you can add to
root = f_A(x) = A · x mod q q = 3⁸, m = 100, n = 1024 one cell changes: f_A(x + Δ·e_j) = f_A(x) + Δ·A[:,j] ⟹ O(m), not O(log N) hashes full recompute of the root 63 813.2 ns incremental update, O(m) 846.4 ns → 75.4× Merkle SHA-256 path, 20 levels ≈ 58 090 ns → 68.6× incremental root == recomputed root → byte-exact, 20 000 updates
This is not an optimisation. It is a property the SHA family provably cannot have.
A hash that is both homomorphic and compressing on a full group has a nontrivial subgroup as its kernel,
and collisions fall straight out of Gaussian elimination. f_A escapes that theorem because its
hash domain is the short set {0,1,2}ⁿ, which is not a subgroup — so any valid collision must be a short
kernel vector, that is, an instance of SIS. Its one-wayness reduces to worst-case SVP (Ajtai, 1996), making it
quantum-resistant under a stated assumption rather than only through Grover-√.
Raw hashing with f_A is 1.4× slower than SHA-256. What you gain is incremental
update, a formal security reduction, and commitment aggregation by addition — not throughput.
04 · Measurement · state dedup
How redundant chain state actually is
| Source — real mainnet | Block | N cells | D cells | N/D | Saved |
|---|---|---|---|---|---|
| transaction calldata | 16 B | 507 737 | 196 367 | 2.59× | 61.33 % |
| transaction calldata | 32 B | 253 868 | 140 545 | 1.81× | 44.64 % |
| contract bytecode | 16 B | — | — | byte metric | 21.70 % |
| contract bytecode | 64 B | — | — | byte metric | 6.05 % |
An earlier version of this page reported 0.57 % for bytecode at 64 B. That figure was an artefact of our own benchmark, which chunked across the concatenated buffer of 383 contracts and so manufactured frame misalignment at every contract boundary. Chunking per object — the correct model of chain state — gives 6.05 % at 64 B and 21.70 % at 16 B.
The correction makes our number look better, which is exactly why it is stated here rather than quietly applied.
We wrote that weak bytecode dedup was caused by frame misalignment, and that content-defined chunking (Rabin/CDC) would fix it. We then measured it. A control test confirms the CDC implementation works: on a deliberately shifted copy, fixed blocks recover 0.38 % while CDC recovers 52.17 %.
But on real bytecode CDC moves 6.05 % only to 7.07 %. So the hypothesis is wrong: the 383 hottest mainnet contracts are simply distinct. EIP-1167 proxies are 45 bytes and rarely sit in the hot-call set. The bytecode figure stays low, in this and every other document.
A second surprise came with it: on calldata, fixed chunking beats CDC by 1.65× (38.30 % against 23.18 %), because calldata has a genuine 32-byte ABI frame that CDC deliberately breaks. The design rule that follows — align to the frame when there is one; use CDC only when there is not — is now a normative clause in the specification.
4 MiB of random data at 32 B blocks: N = 131 072 → D = 131 072, saving 0.00 %. No layer here creates bytes from nothing — all of it harvests redundancy already present in chain data. Shannon's bound and the pigeonhole limit hold.
05 · Devnet
Four validators, actually running
Four separate processes over real HTTP, three-phase consensus in the Tendermint/HotStuff style under f < n/3 — the safety part is not reinvented. Only leader selection and block sizing change with occupation.
T1 consensus 4 nodes at the same height, SAME state root PASS T2 commitment incremental root == recomputed root, byte-exact PASS T3 dedup 1 200 cell writes → 302 cells (3.97×, 74.83 % saved) PASS T4 fault kill 1 of 4 (f=1 < n/3) → the chain keeps committing PASS
The T3 load is devnet traffic we generated, shaped like real calldata. It demonstrates the mechanism; the market measurement is section 04, on mainnet data.
06 · Architecture
One partition function generates the stack
p_i = e^{−βE_i}/Z occupation of a cell
H = −∂lnZ/∂β ⟹ floor on state size (layer L2)
D = 1/Σp_i² ⟹ effective cells after dedup (layer L3)
V = ∂²lnZ/∂β² ⟹ block sizing R(n,ε), not an asymptotic floor
NL1 p(cell) ∝ e^{−β·load} ⟹ shard routing and leader selection
NL3 b ∝ 2^H ⟹ GRANULARITY of a cell ← the crux
State is a set of content-addressed cells. Accounts own no bytes, only references. A duplicate write costs no new cell. Fees are charged per cell touched, not per guessed gas limit.
A three-phase backbone, safe under f < n/3. Leaders are drawn with p(v) ∝ e^{−β·load} rather than
uniformly, because an overloaded leader is where the p99 tail comes from.
N virtual cells on one machine, coordinating through shared memory instead of the network. Because the commitment is homomorphic, aggregating N rollups is one vector addition — no recursive proving.
The VMC-16 machine: a four-nibble instruction word where the five virtualisation layers are addressing modes rather than operating-system services, and authority is an operand rather than file metadata.
Data availability: built on LeanDA, not on our own commitment
Our specification states plainly that f_A gives no succinct membership proofs — a gap we declared
before we knew of LeanDA, which fills exactly
that gap: Reed-Solomon at rate ½ over KoalaBear, Merkle/Poseidon cell commitments, and a STARK proving the committed
object is a valid codeword. The two do not replace each other — f_A commits to live state and updates in
Θ(m); LeanDA commits to an immutable blob and can open a position. What they share is the threat model. Pairing a
lattice state root with a KZG-based DA layer would be incoherent: an attacker with a quantum computer simply walks
through the weaker door.
| Dedup granularity on real calldata | Bytes remaining | Gain |
|---|---|---|
| 32 B — the real ABI frame | 3 652.6 KiB | 2.172× |
| 64 B | 4 895.0 KiB | 1.621× |
| 256 B — LeanDA's cell grid | 6 972.7 KiB | 1.138× |
This is where our Theorem 6 earns its place: deduplicate at the payload layer on the data's natural frame, before the cell grid and the erasure code — never after, since erasure-coded data is near-random and our own control test says dedup then returns exactly 1×. Doing it in the wrong order costs 1.9× of the gain. Projected against LeanDA's published 907.38 KiB/s proving throughput, 2.172× fewer bytes to prove is about 4.72 s of proving saved over this 60-block window.
We have not run LeanVM. That figure is arithmetic over throughput they published, and it assumes throughput scales linearly with payload — which their own post contradicts, since they report proving-time cliffs at powers of two.
Real rollups also compress blobs before posting, so a measurement on raw L1 calldata is an upper bound on the gain, not the gain. And deduplicating across blobs needs shared state that neither system has today. That is unbuilt work, not a feature.
07 · Distribution
The first problem of a new L1 is not TPS. It is that nobody uses it.
The standard answer is grants and airdrops — a positive acquisition cost that stops working the moment the money stops. Exactly two systems in history reached hundreds of millions of users at near-zero acquisition cost. LOGOS-Σ puts both in the protocol layer rather than the marketing layer.
ΣMenu: an on-chain dApp registry ranked by occupation, with a 9 % protocol fee on dApp revenue in place of volatile gas.
Measured on 250 839 real human comments: the top 10.42 % of channels cover 80 % of engagement — almost exactly DoCoMo's 10.71 % curated menu ratio from 1999.
ΣPush: messaging rights issued through a token bucket, with quota allocated by occupation rather than equally, and 85:15 revenue share to developers.
Measured: equal splitting drops 68.70 % of the hottest provider's traffic; occupation-weighted splitting cuts total drop by 1.95×.
When occupation is uniform, all three quota schemes tie (≈1×). ΣPush only pays off under genuine skew. The pigeonhole bound asserts itself here as it does at every other layer of this system.
08 · Project status
What exists and what does not
This is an architecture, a benchmark on real data, and a working devnet. It is not a mainnet.
| Item | Status | |
|---|---|---|
| ✓ | C11 benchmark on real Ethereum state and calldata | done |
| ✓ | Homomorphic state root, byte-exact | done |
| ✓ | Cell-granular sharding with Gibbs routing, on real load | done — routing simulation |
| ✓ | Four-validator devnet, fault tolerance at f = 1 | done |
| ✓ | Content-defined chunking (Rabin/CDC) for bytecode | measured — hypothesis refuted |
| ✓ | Normative specification and analytic proofs | draft v0.1 |
| ○ | OG-BFT across n real machines, real TPS and finality | not yet — 19.45× is not a TPS figure |
| ○ | f_A parameters through an official lattice-estimator run | required before mainnet |
| ○ | Independent cryptographic audit · incentivised testnet | not yet |
| ○ | Legal opinion on token issuance per jurisdiction | not yet |
There is no mainnet, no circulating coin, no sale of any kind, no audit and no legal opinion. Token issuance is a regulated activity in many jurisdictions. This page is a technical document, and what it is asking for is reviewers rather than investors.